← Back to team overview

launchpad-dev team mailing list archive

Re: First cut at recipe db-schema patch

 

Julian Edwards wrote:
> 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 understand that you want to use database constraints to our advantage
but I am not sure I like the idea of SourcePackageRecipeDataBranch rows
having a NULLable Revision foreign key that's set for manifest-type
SourcePackageRecipeData rows but not for the recipe-type rows.

In this particular case the idea of merely keeping the revision database
keys in manifest texts may be the more balanced approach.

>> 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?
If we need to make a distinction between manifest- and recipe-type
SourcePackageRecipeData rows then it's better to have an explicit
discriminator column for that in the SourcePackageRecipeData table.
IMHO explicit is better than implicit when it comes to modelling.

When it comes to indexing on that discriminator column I am not sure how
selective such a "binary" index will be even with a bitmap index scan
(http://en.wikipedia.org/wiki/Bitmap_index).

>>> 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,
Why would we want to embed the database keys of branches in recipe texts
given that each recipe explicitly references all the branches it
utilizes via SourcePackageRecipeDataBranch?
Because branches can be renamed and branch names in recipe texts would
become obsolete?

>> 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.
[..]

Best regards

-- 
Muharem Hrnjadovic <muharem@xxxxxxxxxx>
Public key id   : B2BBFCFC
Key fingerprint : A5A3 CC67 2B87 D641 103F  5602 219F 6B60 B2BB FCFC

Attachment: signature.asc
Description: OpenPGP digital signature


References