31–40 of 117 posts
Earlier quoted context omitted.
Fortunately we're seeing more JS DB libraries offering to read large numbers as the BigInt type.
But frustratingly, a JS BigInt is nothing like a BigInt in any other language. In JS - BigInt is 64bit integer. In anything else - BigInt is a arbitrarily large integer.
Isn't the solution just to use the rowid (after doing the read-id-after-insert dance)? How much trouble does SQLite reysing rowid's actually cause?
Regular rowids are definitely the way to go if you can use them.
Earlier quoted context omitted.
':memory:' https://sqlite.org/inmemorydb.html
Except this source code is not using :memory: The linked source code has (defonce db (d/init-db! "db/db.db" {:pool-size 4 :pragma {:synchronous "FULL"}})) That's writing to disk.
There's only one index so there's no real write amplification. The numbers will go down as you add more data and indexes.
Earlier quoted context omitted.
Fortunately we're seeing more JS DB libraries offering to read large numbers as the BigInt type.
But frustratingly, a JS BigInt is nothing like a BigInt in any other language. In JS - BigInt is 64bit integer. In anything else - BigInt is a arbitrarily large integer.
UUIDs are way over used. There is almost always a better key to use, usually a bigint for databases. If you're making some kind of leaderless distributed data store, then maybe, but even then there are other ID sharding strategies I'd go for first depending on the constraints. For a single database, bigints are smaller and faster, with less footguns. UUIDs can be nice for an opaque public ID, however I'd still prefer…