Ian Monroe wrote:
I do not see how such a major change can be justified in a minor point
release. For instance, currently amaroK does not work when using a
sqlite database on Debian Sid since they package it with sqlite 3.2.5.

Shouldn't this have waited for 4.0?

I agree,

XMMS2 also stoped working for sid and gentoo users and we got a shitload of bugreports.

On the other hand I was forced to rewrite the horrible sqlite3 support.

While on the subject I have a few questions.

How "expensive" is it to open a new sqlite3 handler? My new method doesn't really cache the handlers, could this be a problem?

My new internal api looks something like this:

each part of the code that would like to change something in the db needs to aquire a session:

session = xmms_medialib_begin();

this will open a sqlite3 handler and do some checking of the db.

then make some changes:

xmms_medialib_entry_property_set_int (session, entry, key, value);

and then end it:

xmms_medialib_end (session);

and this will close it.

At first I used a transaction that automaticly begun when you did medialib_begin(). But I got a lot of strange "Database is locked" errors.

This seems to occur when this happens:

thread1: begin
thread2: begin
thread1: insert ()
thread2: select () -> EBUSY
thread1: commit -> EBUSY

to solve this you have to rollback thread2 before you can commit thread1. It was a strange behaviour that didn't fit my code at all so I reverted to not using transactions, this works well but probably hurt my preformance.

Is there a better way to handle this?

-- Tobias

Reply via email to