171–180 of 186 posts
Earlier quoted context omitted.
Are there any other serverless SQL DBMSes?
Lots. Firebird and DuckDB come immediately to mind. Wikipedia lists several more, though not all of them are relational: https://en.wikipedia.org/wiki/Embedded_database
> Bad default #3: SQLITE_BUSY errors with concurrent writers
Earlier quoted context omitted.
> The section "The solution: editions?" in the article addresses directly the point of existing data. I'm sorry, where? SQLite schema is stored as text. If you change the default interpretation of CREATE TABLE with a PRAGMA, your existing tables become STRICT, but (1) they might now have columns with invalid types (which means you have an invalid schema, and your database fails to open), (2) they may have invalid dat…
> > The section "The solution: editions?" in the article addresses directly the point of existing data. > I'm sorry, where? Here: quote [...]This should be a nice middle ground which avoids breaking backwards compatibility , but lets the database engine move forwards and not be bogged down by its own history. end quote > Regarding busy_timeout, why is 5s specifically a better default? According to the post we are dis…
> This should be a nice middle ground which avoids breaking backwards compatibility, but lets the database engine move forwards and not be bogged down by its own history.
Does nothing to address my criticism. Handwaving "this is a nice middle ground" does not address the issues. How does the feature work when enabled on an existing database, and on a new database?
Please understand that when you write `CREATE TABLE …` this statement is copied pretty much verbatim to the schema table. And that's the metadata that's saved for the table: a verbatim copy of the DDL.
If you don't mark it STRICT any current version of SQLite will consider it not to be.
So if you make assuming tables are STRICT the default (even with a PRAGMA), you'll have to deal with tables that you assume are STRICT, but aren't: they have invalid types, or invalid data.
The STRICT feature, as it was added, is backwards compatible in the sense that: (1) all old databases work with new versions of the library, and (2) all new databases fail fast (before corrupting data) in old versions of it, as they'll refuse to parse STRICT tables.
To fail fast for existing database files, you'd need to integrity check the entire databases.
So how do you implement it, what's the alternative, exactly? Add STRICT to every table you create since enabling the PRAGMA? You could do that but, to my knowledge, it'd be the first time you'd do that (modifying the schema before writing it) in 25 years of SQLite.
Whatever you come up with must be backwards compatible, as that is the promise SQLite developers have made.
Counterpoint: each new edition will add bloat to SQLite as future edition will need to keep each past edition pragma set for backward compatibility. As SQLite is often used embedded, bloat matters. So I suggest that "PRAGMA edition" to be only be a shortcut to a list of PRAGMA commands, that would be expanded at the library level: PRAGMA edition would never appear in the DB file. As such, the build of the library wou…
Isn’t that exactly what the author suggests? Editions as a set of config options that are already there. The config options are already implemented, so the heavy lifting is done. Editions would amount to a few hundred bytes.
But figuring that out requires understanding how they are implemented, or reading the forum, which the author admittedly didn't do.
The rest are assumptions about best practices (also not shared by the developers of SQLite).
Earlier quoted context omitted.
> > The section "The solution: editions?" in the article addresses directly the point of existing data. > I'm sorry, where? Here: quote [...]This should be a nice middle ground which avoids breaking backwards compatibility , but lets the database engine move forwards and not be bogged down by its own history. end quote > Regarding busy_timeout, why is 5s specifically a better default? According to the post we are dis…
OK, but this: > This should be a nice middle ground which avoids breaking backwards compatibility, but lets the database engine move forwards and not be bogged down by its own history. Does nothing to address my criticism. Handwaving "this is a nice middle ground" does not address the issues. How does the feature work when enabled on an existing database, and on a new database? Please understand that when you write `…
New database ⇒ use the proposed new magic PRAGMA, start with sane defaults.
Existing database ⇒ don't touch anything, keep legacy "suboptimal" defaults.
> Bad default #3: SQLITE_BUSY errors with concurrent writers This is a weird complaint to me. When I use SQLite, I always make sure there is a single writer thread. Any thread can submit a write request in a thread-safe queue. If you follow this pattern, you never need to worry about SQLITE_BUSY errors.
Earlier quoted context omitted.
> It's reasonable to suggest that the alternative settings for each of these suggestions is probably the wrong default for 2026. That's the key concept here. When tightening up the defaults, an "edition" mechanism is a good solution. Now we need this for C/C++, which have much legacy stuff which ought to go away for new code. This is more feasible than it used to be, because "Convert this Edition 4 code to Edition 5"…
> Now we need this for C/C++, which have much legacy stuff which ought to go away for new code. In C++, certainly. In C, though, what do you not do in C23 that you was doing in C99?
Earlier quoted context omitted.
OK, but this: > This should be a nice middle ground which avoids breaking backwards compatibility, but lets the database engine move forwards and not be bogged down by its own history. Does nothing to address my criticism. Handwaving "this is a nice middle ground" does not address the issues. How does the feature work when enabled on an existing database, and on a new database? Please understand that when you write `…
Not the author of the article, but I think you are overthinking the issue. New database ⇒ use the proposed new magic PRAGMA, start with sane defaults. Existing database ⇒ don't touch anything, keep legacy "suboptimal" defaults.
CREATE TABLE t1(a DATE, b JSON);
PRAGMA strict=ON;
INSERT INTO t1 VALUES(a,b) VALUES(?1,?2);
Just, you know, explain what should happens when you do this, because the creator of SQLite doesn't know.
When doing so consider the file format, how schema is stored, and what happens when other versions of SQLite touch your file.
Should be simple, given that I'm overthinking it. Thanks.