launchpad-dev team mailing list archive

[Michael Hudson <michael.hudson@xxxxxxxxxxxxx>]

Jonathan Lange wrote:
> On Thu, Dec 3, 2009 at 6:24 PM, Michael Hudson
> <michael.hudson@xxxxxxxxxxxxx> wrote:
>> Julian Edwards wrote:
>>> Right, I just had a good call with Jono and we've cleared a bunch of stuff up
>>> between us.
>> Excellent.
>>
>>> The upshot is that you need a few more changes to the schema:
>>>
>>>  1. SourcePackageRecipeData needs a "type" column so we know if it's a
>>> manifest or a recipe.  This will help with indexing, especially since we'll
>>> have loads more manifests than recipes.
>> I'm not sure I see why, but OK.
>>
> 
> 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.

>>>  2. SourcePackageRecipeDataBranch needs a revision number.  This is more
>>> pertinent to manifests but Jono tells me it should be used for recipes too.
>> Um, revision *number*?  I would have thought a text revspec or revision
>> id field would make more sense.
>>
>> I'd like to talk about this bit some more I guess.
>>
> 
> I think Julian meant "foreign key referring to the Revision table".
> 
> 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.

For both this and SourcePackageRecipeData.type, I don't feel these
suggestions are harmful, so I'm happy to be overridden -- but I don't
think they're helpful either.

>   b) Recipes might refer to it
> 
>>>  3. SourcePackageBuildUpload should have a requester column
>> Cool, I'd already come around to this point of view.
>>
> 
> Hurrah for merry agreement.

Yes!

Cheers,
mwh