Re: [sqlite] Problems with threadsafe opt correction #2623
On 9/5/05, Tobias Rundström <[EMAIL PROTECTED]> wrote: > Kiel W. wrote: > > 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. > >> > >> > > Just my two cents, but if this change is breaking things in amaroK, > > XMMS2 and others then more testing should've been done on _those_ > > products before they were released to the wild. Regression/ unit tests > > should be run on most any change but definately when you upgrade a major > > sub-component of your system. > > Well in this case it broke all the currently installed applications that > was installed and where MISSUSING the API. We have corrected this now > but it will take a while before we can make a release out of it. In the > meantime distributions that ship a newer sqlite3 will not be able to use > amarok and xmms2. Well, amaroK bundles sqlite. Its not that fatal. Its just that distributions can't use the system sqlite. > But it was our fault for not reading the docs correctly. > > -- Tobias >
Re: [sqlite] Problems with threadsafe opt correction #2623
On 9/5/05, Kiel W. <[EMAIL PROTECTED]> wrote: > 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. > > > > > Just my two cents, but if this change is breaking things in amaroK, > XMMS2 and others then more testing should've been done on _those_ > products before they were released to the wild. Regression/ unit tests > should be run on most any change but definately when you upgrade a major > sub-component of your system. I was going to make a scarcastic comment involving time machines, but I see your just ignorant of how open source software gets released. We didn't upgrade a major sub-component of our system. Debian Sid did (they're fixing this now). And regardless, it means amaroK can no longer use newer (unpatched) sqlite versions. Thats the actual issue. > --K >
Re: [sqlite] Problems with threadsafe opt correction #2623
On 9/5/05, D. Richard Hipp <[EMAIL PROTECTED]> wrote: > On Mon, 2005-09-05 at 10:57 -0500, 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? > > > > There are no plans at this time to ever release version 4.0. > > SQLite has *never* supported the ability of a handle to be used > by more than one thread. By luck, such use would sometimes work on > some operating systems. But it would fail on others. Such a > situation is very dangerous since if a developer is working on > a system where the misuse of SQLite just happened to work, they > might not detect their design error and then ship non-working code > to a customer where it would fail. A minor change in check-in [2517] > detects the misuse of SQLite on all systems and prevents it from > working even by chance. This allows the problem to be detected > early and corrected before it reaches a customer. But it has already reached our users. amaroK has never had a reported problem with this. In this case "early" is a year or so too late. What about an --incorrect-behavior configuration option? Or a warning to stderr instead? > This is not a design change. This is not an API change. > It does not break backwards compatibility. Um, yes it does. amaroK works with one version of sqlite but not the next. What is the actual definition of backwards compatable? This reminds me of the scene in Office Space where they lay off Milton by "correcting" the accounting error that lead to him continuing to get his checks. :P > All that changed > is that certain errors in the way SQLite is used are now > detected sooner rather than later. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > >
Re: [sqlite] Problems with threadsafe opt correction #2623
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? On Wed, 31 Aug 2005 05:38:05 -0700 D. Richard Hipp wrote: > On Wed, 2005-08-31 at 12:53 +0200, Guillaume Fougnies wrote: > > My code is sharing a pool of SQLite connections on > > multiple databases between a bunch of treatment > > threads. > > Each thread pops a connection from the pool safely > > and push it back once finished. > > > > This works on some systems but not on others. On some > versions of Linux, a thread is not able to override locks > created by a different thread in the same process. When > that happens, a database connection created on one thread > will not be usable by a different thread. > > Additional information: > > http://www.sqlite.org/cvstrac/tktview?tn=1272 > http://www.sqlite.org/cvstrac/chngview?cn=2521
