extragear/multimedia/amarok/src

[Bart Cerneels]

On Tue, Jan 13, 2009 at 11:24 PM, Jeff Mitchell
<kde-dev at emailgoeshere.com> wrote:
> Bart Cerneels wrote:
>> On Tue, Jan 13, 2009 at 8:40 AM, Maximilian Kossick
>> <maximilian.kossick at googlemail.com> wrote:
>>> Why was this committed without proper support for database updates in
>>> SqlCollection? I nearly freaked out when I saw the upgradeVersion1to2
>>> method in DatabaseUpdater. Does anybody here remember the mess that is
>>> A1's database update code? Do we really want to start down the same
>>> path again?
>>>
>>
>> A also don't want the upgrade mess again. However, I've added db
>> upgrade functions like you describe to the SqlPodcasts because there
>> was no upgrade framework in place. The DatabaseUpdater seems to be
>> limited to support SqlCollection only, yet we store a lot more then
>> the basic meta types in the database. So we need a more generic
>> database-updater. I have investigated the problem, but realized I need
>> more knowledge and experience for something like that. I must say I
>> really like the system quassel uses, but that is radically different.
>
> Could you explain this system?  It may be very different, but it doesn't
> (necessarily) mean we couldn't make it work for us.  Or maybe it
> does...but since I don't know the scheme, I have no idea  :-)
>
> --Jeff

Take a look at the code for the sql queries first:
http://git.quassel-irc.org/?p=quassel.git;a=tree;f=src/core/SQL/SQLite;hb=HEAD

I don't have a completely clear picture of the details, it's been a
long time I investigate this.
What it boils down to is that both normal queries and database update
commands are in the db-versions directories. At this moment, in 13/
you can find all the queries used by the current version of
quassel-core. When updating the database each upgrade_*.sql from the
current+1 version up to the new version are run. So updating from
version 10 to version 13 would mean "sqlite3 11/upgrade_*.sql &&
sqlite3 12 && sqlite3 13/upgrade_*.sql".

I'm sure Sput will correct mean since I'm either wrong or inaccurate.

In the past we couldn't use this system easily because of SQL dialects
in the different dbm's we supported. Now that we have standardized on
MySQL switching to this is feasible, but still not trivial.

Bart