[okfn-help] KForge and SQLite

Sat Oct 17 14:49:15 BST 2009

John Bywater wrote:
> Marvelously enough, I got KForge working with SQLite!
> 
> It's still not quite right because, at least by default with SQLobject, 
> SQLite doesn't increment its index when an object is created and 
> immediately purged (the next object unfortunately gets the same id). 
> This causes problems with the service directories being created after 
> the id, which was hoped to be unique. But that's easy to remedy: The 
> service files can be moved to a trash folder when the service is purged. 
> That way, we don't risk deleting critical data, and can maintain a 
> fresher project data folder.

Update: So I just implemented the trash folder, and fixed up all the 
plugins to use the trashServiceFolder() method. KForge with SQLite seems 
to be working fine. Quite an improvement on not being able to create 
tables (circa 2 years hence).

Defaulting to SQLite now seems like a very good idea. It's easy instead 
to use PostgreSQL or MySQL: one can even switch after opening the 
service by dumping data, adjusting the db config section, creating the 
new database, and initialising with dumped data.

J.

PS I've also just removed the dependency on the Python Imaging Library. 
So KForge might now be dependent only on core Python library and 
requirements it can obtain automatically from the Python Cheese Shop. 
:-) But I'll have to check...

> So I was thinking, should this be the default? It's relatively demanding 
> to require a PostgreSQL or MySQL user and database. The difference is 
> probably performance, which would only matter for a larger service. Most 
> KForge services will be small.
> 
> As Trac can run happily off SQLite, why not KForge? I'm thinking of 
> making kforgevirtualenv.py do this by default. Any thoughts?
> 
> John.