Binary incompatibility issue in JuK saved data

[Jaroslaw Staniek]

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)