launchpad-dev team mailing list archive

[Julian Edwards <julian.edwards@xxxxxxxxxxxxx>]

On Thursday 03 December 2009 19:20:26 Michael Hudson wrote:
> > One reason would be to enforce a constraint such that manifest rows
> > always have associated revisions.
> 
> I'm still not sure I buy this -- you cant do this with a database
> constraint, and if you want to check the data in the database you can
> query where the SourcePackageRecipeData is linked from.

Hmm good point, it's a reverse reference.  Maybe Muharem knows a trick?

> > I think Julian meant "foreign key referring to the Revision table".

Probably :)  I'm not familiar enough with the Codehosting schema.

> >
> > The reason is that:
> >   a) Manifests need it
> 
> Well, not really.  This comes back to the "how structured does the data
> in the database need to be" discussion, doesn't it?  The advantage of
> having database level links for branches is to follow renames and
> prevent deletion, neither of which apply to revisions, and if you want
> to model recipes more fully, you need to put much more than just a
> revision link in.

As I understand it, manifests are essentially "frozen" recipes, referring to 
specific revisions.  I was originally thinking it would be useful to store the 
revision in a structured fashion to aid in re-creating the package build.

But reading what you say, I'm not sure any more.  Can we think of any concrete 
use cases with a revision FK present?


Cheers
J