For a while I was attracted to string IDs because of the notion
that "if you're not going to perform arithmetic, it shouldn't be
an int". But ints make way better use of the allotted bits and
I'm loving getrandbits for urandom ID generation.
This change has really made it easier to reason about database
transactions in my projects. When you use 'with db.transaction'
you know for sure that either the db will commit or rollback at
the end and you won't leave in a dirty state. And it will lock
out all other writers so nothing gets messed up.
Previously I was conflating atomicity of each function with
committing of the entire transaction, and that was causing me
grief. I think this is closer to correct.
If the project uses numerical IDs, and processes user input from a web
request URL where everything is a string, it is tedious to convert
between str and int on the application side. If done improperly, it
messes up the cache because the int id and str id will be entered
separately. So we let the database handle the id type and raise errors
if necessary.
This reduces the number of frivolous sql queries we make, since
the index contians all the tables anyway. The side effect is that
the function won't acknowledge tables created during the run time,
which I kind of think is a good thing since it reduces accident
surface area to the tables outlined by the programmer during init.
This helps ensure that the keys of the cache are the true and correct
data type and not just whatever the user provided. SQLite coerces
strings and ints.
