Thread: [SQLObject] Precedence of manually installed pysqlite
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Markus G. <m.g...@gm...> - 2008-11-27 15:35:49
Attachments:
sqlobject-0.10.2.patch
|
Hi, 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? The attached patch reverses the order in which the importing of the respective SQLite modules is performed. Kind regards, Markus |
From: Oleg B. <ph...@ph...> - 2008-11-27 15:45:04
|
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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Markus G. <m.g...@gm...> - 2008-11-27 16:39:06
|
On Thu, Nov 27, 2008 at 4:44 PM, Oleg Broytmann <ph...@ph...> 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 |
From: Oleg B. <ph...@ph...> - 2008-11-27 16:51:27
|
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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2009-01-13 17:09:39
|
On Thu, Nov 27, 2008 at 05:38:59PM +0100, Markus Gritsch wrote: > On Thu, Nov 27, 2008 at 4:44 PM, Oleg Broytmann <ph...@ph...> 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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2008-11-27 19:01:55
|
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 |
From: Oleg B. <ph...@ph...> - 2008-11-27 19:23:12
|
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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Dan P. <da...@ag...> - 2008-11-27 21:09:48
|
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 |
From: Markus G. <m.g...@gm...> - 2008-11-27 22:07:38
|
On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <da...@ag...> 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 |
From: Oleg B. <ph...@ph...> - 2008-11-27 22:11:24
|
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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2009-08-21 17:26:09
|
On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote: > On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <da...@ag...> 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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Oleg B. <ph...@ph...> - 2009-08-26 16:29:53
|
On Thu, Nov 27, 2008 at 11:07:31PM +0100, Markus Gritsch wrote: > On Thu, Nov 27, 2008 at 10:09 PM, Dan Pascu <da...@ag...> 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/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |