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
