61–70 of 99 posts
It’s interesting to read a lot of push back to the points here. I recently built a product with the backend using SQLite as the data store and ran into all these issues and many more. It is frustrating. I use SQLAlchemy and Alembic. It seemed everywhere I turned, the docs said “it works this way in all databases, except SQLite where X isn’t supported or you have to do Y differently.” I think with litestream and D1 an…
Funny! Next do a "First contact with c++ as a Python developer without reading a manual"
Do you think reading the manual is supposed to make those problems disappear or make them less frustrating for some reason? These kind of personal attacks just because their opinion differs from yours is low effort, specially given that they clearly mentioned "official recommendation" in multiple places implying they did go through the manual.
It’s interesting to read a lot of push back to the points here. I recently built a product with the backend using SQLite as the data store and ran into all these issues and many more. It is frustrating. I use SQLAlchemy and Alembic. It seemed everywhere I turned, the docs said “it works this way in all databases, except SQLite where X isn’t supported or you have to do Y differently.” I think with litestream and D1 an…
https://docs.djangoproject.com/en/dev/ref/databases/#sqlite-...
It’s interesting to read a lot of push back to the points here. I recently built a product with the backend using SQLite as the data store and ran into all these issues and many more. It is frustrating. I use SQLAlchemy and Alembic. It seemed everywhere I turned, the docs said “it works this way in all databases, except SQLite where X isn’t supported or you have to do Y differently.” I think with litestream and D1 an…
I'm curious why you used SQLAlchemy and Alembic when (based on your description) Django's support for SQLite sounds a lot nicer? According to the docs, there are a handful of caveats with the Django ORM and SQLite, but nothing too bad it would seem. https://docs.djangoproject.com/en/dev/ref/databases/#sqlite-...
Earlier quoted context omitted.
The wacky approach to column types came from SQLite's origins of being closely integrated with Tcl. Knowing that doesn't somehow mean it was a good default worth carrying on for decades.
Firstly, while it's the default, it's not mandatory. As the author discovered you can use STRICT to make the columns typed, and types to be enforced. The reason it remains unaltered by default is because one of the goals (and accomplishments) of SQLite is that the on-disk-data-file is completely backwards compatible, and cross-platform. This is a very important feature in some situations, and not lightly tossed aside…
CREATE TABLE mytable (
id INTEGER PRIMARY KEY,
created DATETIME,
mything JSON
) STRICT;My mind was blown when i've realized i can write bash command that pipes CSV file into the SQLITE, runs SQL query on it and spits out results. (all completely in ram, without need for temporary sqlite file on disk)
How do you typically deal with "missing features" from SQLite (e.g. stored procedures)? Do you use extensions like https://github.com/nalgeon/sqlean in production?
Don't Application-Defined SQL functions fulfill the role of stored procedures? https://www.sqlite.org/appfunc.html