Binary incompatibility issue in JuK saved data
js at iidea.pl
Tue Jan 8 08:57:15 GMT 2008
Michael Pyne said the following, On 2008-01-08 05:30:
> To cut a long story short however, unless anyone has a better idea my
> intention is to:
> * Bump the JuK version encoded in the playlists file and enforce a specific
> QDataStream version.
> * Read in the files encoded with the KDE 3.5/4.0.0 version as if they were
> saved by Qt 3.3, and add sanity checking checks to force trying to load using
> Qt 4 if that doesn't work. I can't guarantee that this will reliably allow
> JuK in KDE 4.1 or 4.0.1 to load files from 4.0.0 but I think it will at least
> work in most cases.
> I can have the patch developed tomorrow (it's basically just adding
> QDataStream::setVersion() calls and bumping the version JuK saves the file
> under) but I just want to get the problem out there so people know.
> I would recommend that other programs using QDataStream be looked at as well
> (although I wouldn't be surprised if I were the only one surprised by this).
Just a note, not necessary for JuK itself;
Isn't this a lesson for other projects saving to binary formats that it would
be safer to eventually migrate to a structured platform independent storage
like SQLite? (which is now the building block of KDE 4 anyway - in strigi,
akonadi, koffice, amarok, to name a few).
[If you worked with databases a bit, you can stop reading :)]
The cost of retrieval of a single record is O(1) (for random access) and the
retieval itself is touple-based instead of stream-based, so it's possible to
add new fields in a new version of the format without a risk of breaking
backward compatibility or complicating the code.
regards / pozdrawiam, Jaroslaw Staniek
Sponsored by OpenOffice Polska (http://www.openoffice.com.pl/en) to work on
Kexi & KOffice (http://www.kexi.pl/en, http://www.koffice.org/kexi)
KDE Libraries for MS Windows (http://windows.kde.org)
More information about the kde-core-devel