• wetbeardhairs@lemmy.dbzer0.com
    link
    fedilink
    arrow-up
    4
    ·
    13 hours ago

    You can pry sqlite out of my cold dead hands. Because I’ll probably die while using it out of frustration due to the poor performance of triggers.

    • 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
          ·
          3 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)