SQLObject

On Thu, Nov 27, 2008 at 04:35:43PM +0100, Markus Gritsch wrote:
> currently the sqlite3 module is, if present, preferred over a manually
> installed pysqlite2 module.  Therefore it is not possible to use a
> newer version of pysqlite than the one that ships with Python 2.5 and
> 2.6.  Is this really the desired behavior?

   No, and a request to fix this is already in my TODO.

> The attached patch reverses the order in which the importing of the
> respective SQLite modules is performed.

   Thank you very much!

   I think, though, that such a change should be applied to the trunk, not
to the bugfix-only branches.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Thu, Nov 27, 2008 at 4:44 PM, Oleg Broytmann <phd@...> wrote:
>
>   I think, though, that such a change should be applied to the trunk, not
> to the bugfix-only branches.

OK, I don't mind since I use a patched version in the meantime.

However, I wonder about the code in the isSupported() function in
sqlobject/sqlite/__init__.py.  Is this code used at all, and if yes
for what purpose, since it does not check for the sqlite3 module at
all.  Nevertheless my application worked on Python 2.5 without a
manually installed pysqlite package.

Kind regards,
Markus

On Thu, Nov 27, 2008 at 05:38:59PM +0100, Markus Gritsch wrote:
> However, I wonder about the code in the isSupported() function in
> sqlobject/sqlite/__init__.py

   Is is passed to dbconection.ConnectionURIOpener.registerConnection(),
and there it dies because SQLObject doesn't use it further. It seems I can
safely remove the staff.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Thursday 27 November 2008, Oleg Broytmann wrote:
> On Thu, Nov 27, 2008 at 04:35:43PM +0100, Markus Gritsch wrote:
> > currently the sqlite3 module is, if present, preferred over a
> > manually installed pysqlite2 module.  Therefore it is not possible to
> > use a newer version of pysqlite than the one that ships with Python
> > 2.5 and 2.6.  Is this really the desired behavior?
>
>    No, and a request to fix this is already in my TODO.
>
> > The attached patch reverses the order in which the importing of the
> > respective SQLite modules is performed.
>
>    Thank you very much!
>
>    I think, though, that such a change should be applied to the trunk,
> not to the bugfix-only branches.

I think that such a change should not be applied at all. This change will 
make some users happy, but will alienate others, who what to use the old 
default while they may have both installed for reasons of their own. 
There shouldn't be a hardcoded choice of one version over the other if 
everybody is to be happy (the assumption that all people having both 
sqlite3 from python2.5+ and pysqlite2 installed prefer pysqlite2 doesn't 
hold water; same for the other way around)

A better solution would be to somehow (maybe using a module parameter) 
indicate which is preferred (having a default that points to the most 
common/used one in case nothing is indicated by the user).

Or maybe some parameter to the dburi (like backend) would be simpler and 
cleaner.

-- 
Dan

On Thu, Nov 27, 2008 at 09:01:41PM +0200, Dan Pascu wrote:
> I think that such a change should not be applied at all. This change will 
> make some users happy, but will alienate others, who what to use the old 
> default while they may have both installed for reasons of their own. 
> There shouldn't be a hardcoded choice of one version over the other if 
> everybody is to be happy (the assumption that all people having both 
> sqlite3 from python2.5+ and pysqlite2 installed prefer pysqlite2 doesn't 
> hold water; same for the other way around)

   Yes, you have a point.

> A better solution would be to somehow (maybe using a module parameter) 
> indicate which is preferred (having a default that points to the most 
> common/used one in case nothing is indicated by the user).
> 
> Or maybe some parameter to the dburi (like backend) would be simpler and 
> cleaner.

   Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Thursday 27 November 2008, Oleg Broytmann wrote:
> > Or maybe some parameter to the dburi (like backend) would be simpler
> > and cleaner.
>
>    Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.

My preference would be towards the last example using a backend parameter, 
because that would avoid the need to invent new db scheme names. By using 
this we can even choose between sqlite1 and 2 (which is again a hardcoded 
choice if both are installed). Having new db scheme names is probably 
going to be more complicated, because it would probably imply that we 
have to define them as distinct backends.

Also the backend arg should be just a preference, which should override 
the default choice of the most recent backend as is done now. I still 
think that having the default to choose the most recent backend available 
is still a good strategy, but being able to manually override it using 
the backend parameter, would give full flexibility to everyone. This way 
it will still work out of the box, without any change, for people who do 
not care about the backend, or who only have one installed.

-- 
Dan

On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <dan@...> wrote:
> On Thursday 27 November 2008, Oleg Broytmann wrote:
>> > Or maybe some parameter to the dburi (like backend) would be simpler
>> > and cleaner.
>>
>>    Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.
>
> My preference would be towards the last example using a backend parameter

Me too.  Using 'sqlite2' as name is IMO not correct.  'pysqlite2'
would be more appropriate but this makes it look weird at the URI
beginning.  Appending ?backend=sqlite3 or ?backend=pysqlite2 looks
nice.

> Also the backend arg should be just a preference, which should override
> the default choice of the most recent backend as is done now.

Currently the precedence is
1. sqlite3
2. pysqlite2
3. sqlite

Since sqlite3 is bundled with Python, it get's outdated by more recent
versions of pysqlite2 quite quickly.  So if it is desired to have as
default the most recent version, the default order if no parameter is
specified should be

1. pysqlite2
2. sqlite3
3. sqlite

> I still
> think that having the default to choose the most recent backend available
> is still a good strategy, but being able to manually override it using
> the backend parameter, would give full flexibility to everyone.

Agreed.

Kind regards,
Markus

On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote:
> Currently the precedence is
> 1. sqlite3
> 2. pysqlite2
> 3. sqlite
> 
> Since sqlite3 is bundled with Python, it get's outdated by more recent
> versions of pysqlite2 quite quickly.  So if it is desired to have as
> default the most recent version, the default order if no parameter is
> specified should be
> 
> 1. pysqlite2
> 2. sqlite3
> 3. sqlite

   I agree.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Thu, Nov 27, 2008 at 05:38:59PM +0100, Markus Gritsch wrote:
> On Thu, Nov 27, 2008 at 4:44 PM, Oleg Broytmann <phd@...> wrote:
> >
> >   I think, though, that such a change should be applied to the trunk, not
> > to the bugfix-only branches.
> 
> OK, I don't mind since I use a patched version in the meantime.

   I applied your patch in the revision 3669.

> However, I wonder about the code in the isSupported() function

   Removed in the r3770. Thank you!

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote:
> On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <dan@...> wrote:
> > On Thursday 27 November 2008, Oleg Broytmann wrote:
> >> > Or maybe some parameter to the dburi (like backend) would be simpler
> >> > and cleaner.
> >>
> >>    Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.
> >
> > My preference would be towards the last example using a backend parameter
> 
> Me too.  Using 'sqlite2' as name is IMO not correct.  'pysqlite2'
> would be more appropriate but this makes it look weird at the URI
> beginning.  Appending ?backend=sqlite3 or ?backend=pysqlite2 looks
> nice.

   I did the first step to implement this - removed global variables;
imported DB API driver stored as self.module. I hope to implement backend
selection next week.

> > Also the backend arg should be just a preference, which should override
> > the default choice of the most recent backend as is done now.
> 
> Currently the precedence is
> 1. sqlite3
> 2. pysqlite2
> 3. sqlite
> 
> Since sqlite3 is bundled with Python, it get's outdated by more recent
> versions of pysqlite2 quite quickly.  So if it is desired to have as
> default the most recent version, the default order if no parameter is
> specified should be
> 
> 1. pysqlite2
> 2. sqlite3
> 3. sqlite

   This was changed in 0.11.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote:
> On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <dan@...> wrote:
> > On Thursday 27 November 2008, Oleg Broytmann wrote:
> >> > Or maybe some parameter to the dburi (like backend) would be simpler
> >> > and cleaner.
> >>
> >>    Either sqlite2://, sqlite3:// - or sqlite://...?backend=sqlite2.
> >
> > My preference would be towards the last example using a backend parameter
> 
> Me too.  Using 'sqlite2' as name is IMO not correct.  'pysqlite2'
> would be more appropriate but this makes it look weird at the URI
> beginning.  Appending ?backend=sqlite3 or ?backend=pysqlite2 looks
> nice.

   Done in revision 3967. Will be in 0.12.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            phd@...
           Programmers don't die, they just GOSUB without RETURN.