There are several things happening with the package DB this week. 1) Jesse Keating reported that the Brew buildsystem has a packagedb implementation. If approval goes through to open source brew, we'll get the schema for that packageDB as part of the package. I know of a few areas where we'll have to enhance the schema to support all the things we want to do (ACLs for building, committing, and modifying packageDB records) but am unclear on others (Does the brew packageDB have a web interface? Does it tie into Core's CVS?) 2) I've finished an importer for owners.list and some information from the CVS repository for the current schema. I haven't tested it extensively but it has imported data into my local test DB. I'll have to try it on the xen test server next. The importer separates the exporting functionality from the importing so it shouldn't be too hard to switch to a new packagedb schema later. The importer is owners.py on test3: test3.fedora.phx.redhat.com:/var/www/repo/fedora-packagedb/owners.py Or available from a Bazaar repository: bzr branch http://www.tiki-lounge.com/~toshio/fedora/fedora-packagedb 3) I've started a redesign of the schema to address ACLs and collection inheritance. I've some questions about this that I'll try to take up with Jesse this week. I'm writing up the schema in SQL now and will post it this week for review. 4) While working on the schema, I've become a bit less enamoured with SQLObject. It seems to make easy things easy and hard things difficult to impossible. For instance, there doesn't seem to be a way to specify multi-field primary keys (or multi-field unique constraints which would do almost as well.) The latest TurboGears beta has preliminary support for a second ORM, SQLAlchemy. I've installed the 0.3.1 of SQLAlchemy here and it is much more flexible. SQLAlchemy is newer than SQLObject, has excelent documentation, and a very active upstream. This is good in that bugs are fixed quickly and features are often added once a user requests them. It's downside is the potential that the API could change and we'd have to port our applications or stay with an older version. Any opinions on this? -Toshio
Attachment:
signature.asc
Description: This is a digitally signed message part