4 ms·

I intend to support SQLite for 33 more years. I take that commitment seriously and plan accordingly. But even if my plans do not work out, the SQLite file for

by SQLite 10y ago

I intend to support SQLite for 33 more years. I take that commitment seriously and plan accordingly. But even if my plans do not work out, the SQLite file format is fully documented and relatively simple. See https://www.sqlite.org/fileformat2.html https://www.sqlite.org/fileformat2.html for details. Writing a script to convert an SQLite database into a series of CSV files shouldn't take a competent hacker more than a few of hours and a novice more than a few days. Reasonable estimates are that there are more copies of SQLite in use today than any library other than zLib. I dare say that SQLite will live as long or longer than gzip, and should both disappear, I suspect you will have a much easier time recovering content from an SQLite database than you would from a gzip file.

avh02 10y ago
Oh wow, hello! * blush * Serious (if redundant) question though: on year 34, is backward compatibility out the window? (that said, 33 years is probably enough time to make the standard fairly permanent anyway, so even if the developers decide to break it, there will be enough residue that I don't believe the then-old standard could disappear)
user5994461 10y ago
Tsss. Amateur mistake. It doesn't matter how long your brand will live, the problem is how long the version used to make the backup will live. Let's make a backup with SQLite(Lib) 2017. Somewhen in 2030, we'll try to recover that backup. First, we realize that SQLite[Lib] 2030 can't read it. Because there were subtle changes on the format and the applications/librairies binaries for whatever reason and it cannot read that file anymore (even though everyone guaranteed that it would be readable for the next 33 years). So we look for a version of SQLite 2017 (or as close as we can get). Maybe we find one, maybe we don't. Let's say we find one... we try it and it doesn't work on Linux Redbian 2030. So we need to find an old OS from 2017. Let's assume we find one... but it doesn't recognize the current Motherboard and it cannot run on Intel 96 bits processors. So we gotta find a VM or an old computer in a garage... And we'll stop there because it's endless.

by SQLite 10y ago

avh02 10y ago

Oh wow, hello! * blush * Serious (if redundant) question though: on year 34, is backward compatibility out the window? (that said, 33 years is probably enough time to make the standard fairly permanent anyway, so even if the developers decide to break it, there will be enough residue that I don't believe the then-old standard could disappear)

user5994461 10y ago

Tsss. Amateur mistake. It doesn't matter how long your brand will live, the problem is how long the version used to make the backup will live. Let's make a backup with SQLite(Lib) 2017. Somewhen in 2030, we'll try to recover that backup. First, we realize that SQLite[Lib] 2030 can't read it. Because there were subtle changes on the format and the applications/librairies binaries for whatever reason and it cannot read that file anymore (even though everyone guaranteed that it would be readable for the next 33 years). So we look for a version of SQLite 2017 (or as close as we can get). Maybe we find one, maybe we don't. Let's say we find one... we try it and it doesn't work on Linux Redbian 2030. So we need to find an old OS from 2017. Let's assume we find one... but it doesn't recognize the current Motherboard and it cannot run on Intel 96 bits processors. So we gotta find a VM or an old computer in a garage... And we'll stop there because it's endless.