Package DB Schema v3

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pkgdb.sql
Type: text/x-vhdl
Size: 14369 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061204/55bc941c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061204/55bc941c/attachment.sig>