launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #01826
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