[Trac] Trac and sqlite3

Clay Loveless clay at killersoft.com
Mon Mar 7 13:09:54 EST 2005


On 3/7/05 9:16 AM Pacific Time, Christopher Lenz (cmlenz at gmx.de) wrote:

> Actually, I think it's just a matter of choosing between pysqlite <= 1.0.x
> and pysqlite >= 1.1.x. The latter uses the SQLite 3 APIs, while the former
> uses SQLite 2.
> 
> This has the side-effect that you can't have both SQLite 2 and 3 Trac
> environments on the same machine (without some hacking), because the
> choice is made by which pysqlite version Trac finds on the Python path.

Hmmmm... This exceeds my current understanding of Python. : )

I recognize that my Python path is: /usr/lib/python2.3/site-packages
(right?)

And I can see that `dpkg --list` tells me I've got python-sqlite 1.0.1
installed.

I can also see that pysqlite.sourceforge.net points me to pysqlite.org,
which has a lovely series of photos of some cats, but no helpful information
about pysqlite 1.0 vs 1.1.

PyPI on python.org makes no mention of pysqlite beyond 1.0.

Not sure where to go from here. I'm not concerned about conflicting versions
of sqlite ... Currently, all I'm using sqlite for is trac. I'm also not
worried about compiling my own libraries, if necessary. Debian package
installations are more convenient, but I don't mind getting out of those
occasionally if there's a benefit.

Which brings me back to the sqlite2 vs sqlite3 performance question as it
relates to trac. Based on the "Improved Concurrency" section of this
document:

http://www.sqlite.org/version3.html

... I'm assuming that's a benefit to a busy trac project in terms of
performance. Chris, can you please address that question?

Thank you! I apologize for my Python ignorance. : )

Regards,
Clay

-- 
Killersoft.com





More information about the Trac mailing list