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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
