4 ms·

In the example the user has to create the schema and manually open the SQLite connection, can't you abstract that away?

abound 3y ago
Not the author, but I imagine most projects already have a way of managing their SQLite schema (e.g. a migration system like go-migrate or goose) that they'd integrate the new table(s) into.
- markusw 3y ago
  This exactly. If you're using SQLite in your Go project, you most probably already have your sql.DB and schema migrations sorted, so I don't want to get in the way of that. :) (But I can see how that could be clearer from the example code. I think I'll add that as comments. Thank you for the feedback!)
  - markusw 3y ago
    I've updated the code example to reflect this.
- whalesalad 3y ago
  Wouldn't you want to use a different db file for this? I wouldn't want to put this in the same db as the rest of my app, especially considering how simple it is to just open a new file.
  - markusw 3y ago
    If you want to be able to send to the queue in the same transaction as other state changes, it has to be the same file. That’s often a useful property.
    - lifeinthevoid 3y ago
      SQLite allows transactions involving multiple databases (see https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html section 5)
      - markusw 3y ago
        Oh! TIL! Thank you for that. :)
      - yard2010 3y ago
        SQLite is such a great thing. Amazing value for zero cost both shmeckels and maintenance. It's a shame most startups go for postgres blindly due to "scalability concerns" it feels like a major case of premature optimization.
        markusw 3y ago
        It really is! I've become a SQLite fanboy. :D Although I can definitely see the value in Postgres as well. But it's usually one of those two.
        pdimitar 3y ago
        My beef with SQLite is the weaker typing + not even enforcing foreign keys unless you open the DB in a certain mode. IMO it should become more opinionated and stricter. I'd honestly pay to buy a license for SQLite with the legacy baggage removed and rewritten to be as strict as PostgreSQL or more. Well... basically embedded PostgreSQL I guess.
        markusw 3y ago
        I also don’t like those parts, but for an otherwise great project, I’d happily use the parts I do like. Strict tables go a long way for me, and you can make foreign key checks a compile-time enforcement.
        pdimitar 3y ago

Not the author, but I imagine most projects already have a way of managing their SQLite schema (e.g. a migration system like go-migrate or goose) that they'd integrate the new table(s) into.

markusw 3y ago
This exactly. If you're using SQLite in your Go project, you most probably already have your sql.DB and schema migrations sorted, so I don't want to get in the way of that. :) (But I can see how that could be clearer from the example code. I think I'll add that as comments. Thank you for the feedback!)
- markusw 3y ago
  I've updated the code example to reflect this.
whalesalad 3y ago
Wouldn't you want to use a different db file for this? I wouldn't want to put this in the same db as the rest of my app, especially considering how simple it is to just open a new file.
- markusw 3y ago
  If you want to be able to send to the queue in the same transaction as other state changes, it has to be the same file. That’s often a useful property.
  - lifeinthevoid 3y ago
    SQLite allows transactions involving multiple databases (see https://www.sqlite.org/atomiccommit.html https://www.sqlite.org/atomiccommit.html section 5)
    - markusw 3y ago
      Oh! TIL! Thank you for that. :)
    - yard2010 3y ago
      SQLite is such a great thing. Amazing value for zero cost both shmeckels and maintenance. It's a shame most startups go for postgres blindly due to "scalability concerns" it feels like a major case of premature optimization.
      - markusw 3y ago
        It really is! I've become a SQLite fanboy. :D Although I can definitely see the value in Postgres as well. But it's usually one of those two.
      - pdimitar 3y ago
        My beef with SQLite is the weaker typing + not even enforcing foreign keys unless you open the DB in a certain mode. IMO it should become more opinionated and stricter. I'd honestly pay to buy a license for SQLite with the legacy baggage removed and rewritten to be as strict as PostgreSQL or more. Well... basically embedded PostgreSQL I guess.
        markusw 3y ago
        I also don’t like those parts, but for an otherwise great project, I’d happily use the parts I do like. Strict tables go a long way for me, and you can make foreign key checks a compile-time enforcement.
        pdimitar 3y ago