At 4:01 PM -0400 6/26/06, [EMAIL PROTECTED] wrote:
Peter Bierman <[EMAIL PROTECTED]> wrote:
At 2:20 PM -0400 6/26/06, [EMAIL PROTECTED] wrote:
>SQLite 3.3.0 can read and write all prior versions of SQLite
>databases. But SQLite 3.2.8 cannot read or write a database
>created by SQLite 3.3.0, unless you use
>
> PRAGMA legacy_file_format=TRUE;
>
>prior to creating the database, or unless you compile 3.3.0
>with -DSQLITE_DEFAULT_FILE_FORMAT=1.
Does this forward-incompatibility include the PRAGMA user_version?
Ie., Can 3.2.8 read at least the user_version from a 3.3.0 file, even
if it can't read anything else?
No.
Oy. Is there any way for a 3.2.x or earlier library to detect this situation?
(Maybe no way via the sqlite APIs, but probably a file format version
at a known offset?)
Let me reemphasize that the new file format has caused so much
grief that I will likely revert to the older format with 3.4.0.
That is to say, databases created by 3.4.0 will be readable by
3.2.8. 3.4.0 will be able to read and write both the old and the
new formats, of course. And you will still be able to use the new
format using a pragma or a compile-time option. It just won't be
the default any more.
I have learned my lesson. Do not enhance the file format without
a very good reason. Saving one byte of space when storing booleans
is not a sufficiently good reason...
:-)
Progress is good, I just need a way to distinguish progress from
errors. I thought the user_version PRAGMA would be the one safe value
that any version could read from any other version.
What's the rough time line for 3.4.0? (Or even a 3.3.x that reverts
the file format.) It would be unfortunate if the next release of Mac
OS X shipped with this issue.
-pmb
