← Back to team overview

launchpad-dev team mailing list archive

Re: First cut at recipe db-schema patch

 

Muharem Hrnjadovic wrote:
> Michael Hudson wrote:
>> Muharem Hrnjadovic wrote:
>>> Michael Hudson wrote:
>>> [..]
>>>>>>> Comments welcome -- it would be nice to land this this cycle so we can
>>>>>>> start working on things for realz next cycle.
>>>>>> Screw this part: we can just land it on db-devel.  Rushing is bad
>>>>> Agreed.
>>>> Cool.
>>>>
>>>> Thanks for the comments!  (and sorry for all the typos in my first post).
>>>>
>>>> There's a new patch at http://pastebin.ubuntu.com/332821/
>>> Could you please explain why you have both a SourcePackageBuild and a
>>> SourcePackageBuildUpload table? Could the data stored in the latter
>>> table not live in the former as well?
>> Because Julian asked for the ability to upload the output of one recipe
>> build to be uploaded to multiple archives.
> 
> Hello Michael,
> 
> thanks for the explanation. I realized that I probably did not strike
> the right note in the other email on the subject, so let me try to amend
> by asking a few questions:

Well, your other mail pointed out areas I had been less than clear in my
intent!

> What is the advantage of introducing the SourcePackageRecipeData table?
> Why not just have a text field where ever that table is referenced?

I hope I've (finally) adequately explained this in the reply I've just
sent to Julian.

> Why do both SourcePackageRecipe and SourcePackageBuild have a distroseries
> foreign key?

Paranoia on my part -- SourcePackageRecipe.distroseries is the
distroseries the recipe is attached to *now*,
SourcePackageBuild.distroseries is the distroseries the recipe *was*
attached to when the recipe was built.  If
SourcePackageRecipe.distroseries never changes, maybe there's no problem
here.  There is something lurking around here to do with what happens
when a new distroseries is opened for development, perhaps...

Cheers,
mwh



References