• RustyNova@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    10 hours ago

    Tbh trigger performance isn’t that much of a concern unless you need to write lots of data, which most usage don’t need.

    Also try check statements instead or even re-evaluate your schema to prevent them if you really need to.

    Personally my death would be multiple write transaction deadlocks. Sadly it doesn’t play that well with async code, like with sqlx (rust).

      • RustyNova@lemmy.world
        link
        fedilink
        arrow-up
        2
        ·
        4 hours ago

        This is also part of my death, because it’s much easier to not deadlock when you are FIFO.

        Personally I went for the nuclear option, and any transaction is sent as a tokio task to make sure the transaction keeps getting polled despite other futures getting polled. Coupled with a generous busy timeout timer (60secs) and Wal mode, it works pretty well.

        Probably should also put the mutex strategy (perhaps a tokio semaphore instead?) although due to lifetimes it might be hard to make a begin() function on my DB pool wrapper.

        … Congratulations. You nerd snipped me. Time for it to go on the todo stack.

        Hyped for it too, but wouldn’t use until sqlx suport. Compile time checked queries are just so good. I don’t use rustsqlite for that reason alone (you often don’t need async SQLite anyways)