← Back to context

Comment by Rendello

5 hours ago

> SQLite is slightly different from Rust in that it is a data container.

I think this is the key.

From sqlite.org [1]:

> [Since 2004], the file format has been fully backwards compatible.

> By "backwards compatible" we mean that newer versions of SQLite can always read and write database files created by older versions of SQLite. It is often also the case that SQLite is "forwards compatible", that older versions of SQLite can read and write database files created by newer versions of SQLite. But there are sometimes forward compatibility breaks. Sometimes new features are added to the file format

---

Given editions (A) and (B), what does backwards compatibility look like? Must (B) be backwards compatible with (A)?

If yes -> editions are backwards compatible but not necessarily forwards compatible, which is the current status quo:

    -------(A)----(B)--

If no -> editions are not backwards compatible, the edition space is bifurcated:

    ---+----(A)--------
        \
         \--(B)--------

Now you may have to worry about backwards compatibility with (A)..(Z). What happens when you import a file from edition (Y)?

1. https://www.sqlite.org/formatchng.html

---

Interesting PS, grepping sqlite.org for "backwards compat": https://pastebin.com/Q7b7h4eM

2 comments

Rendello

Reply
mort96  5 hours ago

The answer to the question "What happens when you import a file from edition (Y)" should, ideally, be exactly the same as the answer to the question "What happens when you import a file created with parameters foo, bar and baz set to values a, b and c". There's really nothing new here.

Some parameters are properties of the database file itself, such as (I believe) journal_mode. These parameters probably result in issues with earlier versions of sqlite; if you create a file with journal_mode WAL, you're not gonna be able to open it in a version of sqlite without WAL support. Same with strict tables; if you have a database which contains strict tables, I assume you're going to encounter issues if you try to open it in a version of sqlite too old to support strict tables. But anything new enough to support the individual database file features shouldn't have any trouble. This is true whether we're talking about an edition pragma or individual parameters set the old way.

Some parameters are properties of the connection, like the foreign_keys parameter. If you're trying to open a database file in a version of sqlite which doesn't support foreign key validation at all, just don't set the foreign_keys parameter.