← Back to team overview

launchpad-dev team mailing list archive

Re: First cut at recipe db-schema patch

 

Michael Hudson wrote:
> The branch at ~mwhudson/launchpad/recipe-db-schema adds a patch to add
> SourcePackageRecipe, SourcePackageRecipeBranch and
> BuildSourcePackageFromRecipeJob tables.  You can also see it at
> http://pastebin.ubuntu.com/327343/.

I talked to Jono and Julian a bit, and have made some changes.  New
patch at http://pastebin.ubuntu.com/328140/ .  It's certainly a fairly
large patch and I'd feel a little uncomfortable about landing it without
some model code (at least) to back it up.

> I think it's mostly fairly uncontroversial.  Some remaining points:
> 
>  - My unique index assumes that the url will be
> https://launchpad.net/ubuntu/sourcepackage/+recipe/name or very similar.
>  Arguments welcome about whether the owner should be in there :-)

I think we should keep the name in the url.

>  - The big missing part is where to store the log file and manifest that
> are produced by the job's execution.  We could be more like the existing
> Soyuz code and have a separate "Build" table that points at these
> things, or they could live on BuildSourcePackageFromRecipeJob

I think a separate SourcePackageRecipeBuild table mimicing Build (hey,
anyone want to rename that BinaryPackageBuild or something? ;-) makes
most sense, so I've added that.

>  - This doesn't get into the mess of SourcePackageRecipe subscriptions.
> 
>  - My patch assumes that a built sourcepackage will be uploaded uploaded
> to exactly one archive.  Julian expressed some concerns about wanting to
>  be able to upload to more than one, but I think we can probably survive
> without this for now.

This is still true and I'd still like someone to shout if they disagree :)

>  - There was talk earlier about needing to record who requested a source
> package build; it turns out that Job already has a requester field, so
> we don't need one on BuildSourcePackageFromRecipeJob.

However, if the Job row goes away before the SourcePackageRecipeBuild
row, then we'd lose that.  I still don't know where to store it.  In the
existing model I think this sort of thing is tracked in the
SourcePackageRelease table (correct?) which we don't have an analogue
for yet in the build from recipe world -- I don't know if we need one
though as SourcePackageRelease <-> Build is 1-to-many in a way that
doesn't apply to recipes.

What I think I'm trying to say is that who requested the recipe be built
into a source package can be stored in the SourcePackageRecipeBuild table.

> 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

Cheers,
mwh



Follow ups

References