Package DB Schema v3

I'm attaching my latest incarnation of the PackageDB schema. Here's the run down on what's changed: * Implementation of Collection inheritance/overlays/sets * Add a reviewURL field to Package * Restructure the Package hierarchy slightly: Old: Package Collection | | PackageListing | PackageVersion New: +-Collection Package | | | | | PackageListing PackageVersion | | +----------------->PackageVersionListing The new structure allows a PackageVersion to exist in multiple collections which Jesse says is beneficial when spinning short-term, collections. * PackageInterest revamped as a PackageACL set of tables. Instead of having user roles (comaintainer, watcher, etc) we have functions that the user can perform. The functions I've come up with so far are: - commit: Commit changes to the VCS - build: Request builds from the buildsystem - watchbugzilla: Be informed of bugzilla tickets - watchcommits: Be informed of VCS commits for this package - approveacls: Change these ACLs for this package - checkout: Checkout the package from the VCS. We'll normally set this to true for a group that includes everyone but certain embargoed branches may need to be set to a more restricted group. Owners will implicitly have access to all of these. Sponsors or the equivalent group of trusted contributors under the merged FC/FE will belong to a group with commit-build-approveacls-checkout permissions. Things that still need working on: * Integrating comps/categories. I have some notes in comments. In order to implement this we need to 1) decide if comps is the right thing for this or if something closer to Nicolas Mailhot's suggestion is the right way to go. 2) Give the PackageDB an understanding of binary packages/subpackages as groups and categories won't be the same for each subpackage. [Note unless someone wants to work on this, I'm deferring it to after the first iteration.] * Logging. Make sure we have all the tables we need for logging. Verify that we really need to log on all these areas. Collections, Packages, PackageListing(aka package in Collection), PackageVersion, and PackageACL all have status fields so they should all have logs or we need to evaluate whether we really want status for each of these. * CollectionSets: Overlays can now be tracked in the database but the logic for looking for packages has to be implemented. After talking with Jesse, I think the simplest may be to implement this in application code so that searching for a package will first check the collection, then each of its bases. However, this imposes a performance penalty on each select. It *may* be worthwhile to look into copying the packages to the relevant overlay collections on insert instead. I have some notes as comments in the schema. * Set things up for SQLObject and SQLAlchemy. I'm going to try loading the objects through database introspection and see how the two ORMs fare. -Toshio