PackageDB progress

Toshio Kuratomi a.badger at gmail.com
Sun Nov 26 22:20:53 UTC 2006


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20061126/9bd24acb/attachment.bin 


More information about the infrastructure mailing list