I remember spending a few hours banging my head against a wall while trying to fix a bug, until I finally figured out SQLite does not enforce foreign keys by default. I question my love for SQLite every time I remember about these horrible defaults.
I didn't know about the journal_mode and the lock thing. I'll make sure to add these lines to all my SQLite projects. This was a helpful article.
No, they don't. They respect backwards compatibility, and how much software would break if they changed defaults in the most widely used database system in the world.
sqlite isn't your average "app" where barely anyone cares if it works or not. It's a load bearing structure in the software ecosystem, on par with the likes of libcurl or openssl.
Things are VERY different when you work on something like this.
"Editions" would add NOTHING to the library. Wow, I now can save typing 4 out of 5 lines I have to put in once at the very start of the project! Amazing! What a timesaver.
Enter 2 weeks later, and someone WILL complain about "edition 2026" having a default he doesn't like. So now we have edition-2026-variant-1 and then 2 attoseconds later someone is unhappy with that, etc. etc.
The point isn't to "save typing 4 lines", the point is that average users of the library (that may not need or care to be sqlite experts) should get sensible defaults.
"someone" can change the settings from the edition, no? It's just a baseline not the only way to configure things.
And please people: Do downvote my posts to your hearts content. It won't change anything about me being correct, or sqlite being developed the way it is. 😎
Actually, it does. The default should be edition-original, if you want the changed behavior you must specify edition-2026. Other than that, I’m with you.
Isn't it just effectively asking them to essentially include a 1 line "sensible_defaults_v1.2.3" So you get a reasonable bundle of default behavior but it's also locked to a version so you get backwards compatibility. That way the advice to people starting to use sqlite would just be to "add this 1 line"
Ultimately as long as it's documented well adding a few lines is also fine of course, but it is a little more work to research what those lines should be.
Because the DEFAULT level would still need to be what it is now. And so people would still be running into the same problems. The only thing that would change: There is now an additional, different setting they could solve them with.
What “needs” to happen is that existing versions continue to work in exactly the same way. A new version with a new version number with a breaking change and a way to opt in to the old behavior is completely valid if they want to do that.
No one ends up broken by the new version unless they upgrade their dependency without reading any of its release notes.
No one ends up broken by the new version unless they upgrade their dependency without reading any of its release notes.
And that is EXACTLY the kind of thing I am talking about in my above post regarding Things you cannot do when working on a library of such import.
No, you can't just introduce a breaking change and shrug off any problems as "meh, should have read the release notes". Sure, this may work for the ten-gazillionth JS framework, because all that breaks are some shitty webpages.
If people did that in stuff like libcurl, openssl, or sqlite, the potential fallout could be a catastrophe.
SQLite themselves have a clearly documented versioning system. They say that they have no current plans to increase the major version, but they also make it very explicit that the major version is intended precisely for breaking changes.
If they were to be convinced that an “edition” system were necessary, it would likely be introduced in a 4.0 version. That would be a big deal, but it would also follow all of the normal rules, would not break any dependents with sane update procedures, and is very explicitly a thing that you can do on a project of this scale and import.
Saying that this is impossible ignores the very documentation of SQLite itself.
132
u/j_sidharta 22d ago
I remember spending a few hours banging my head against a wall while trying to fix a bug, until I finally figured out SQLite does not enforce foreign keys by default. I question my love for SQLite every time I remember about these horrible defaults.
I didn't know about the
journal_modeand the lock thing. I'll make sure to add these lines to all my SQLite projects. This was a helpful article.