launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

On Thu, Nov 26, 2009 at 2:02 AM, Michael Hudson
<michael.hudson@xxxxxxxxxxxxx> wrote:
> 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.
>

Me too.

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

name, yes. I also think we should have the owner.

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

Renaming, eh? We should do more of it.

>>  - 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 :)
>

To clarify, a single recipe can be built to more than one archive --
that is, a recipe is not bound to a single archive -- but it doesn't
need to have a single job that builds it to multiple archives.

Maybe that doesn't clarify at all.

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

This sounds OK to me.

>> 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
>

+1

Although my hunch is that the schema supports it, it's not obvious
from reading the SQL code where the recipe manifests would go. Another
reason why model code would help.

jml