Muharem Hrnjadovic wrote:
> I read through the "First cut at recipe db-schema patch" email thread again..
>
> Just in case you plan to keep the revision data for manifests in the SourcePackageRecipeData.recipe text column: how do we distinguish between recipe and manifest data w/o looking at the .recipe content or checking that it was referenced via SourcePackageBuild.manifest?
I guess I was expecting that you wouldn't do a big query for all
SourcePackageRecipeData rows referencing a branch and the split them
into recipe and manifest links but rather do two queries, one for
recipes referencing a branch and then one for manifests/build logs
referencing a branch. In my model code currently, there is no interface
for SourcePackageRecipeData -- it's hidden within the
SourcePackageRecipe content type.
Muharem Hrnjadovic wrote: cipeData. recipe text column: how do we distinguish between recipe and manifest data w/o looking at the .recipe content or checking that it was referenced via SourcePackageBu ild.manifest?
> I read through the "First cut at recipe db-schema patch" email thread again..
>
> Just in case you plan to keep the revision data for manifests in the SourcePackageRe
I guess I was expecting that you wouldn't do a big query for all cipeData rows referencing a branch and the split them cipeData -- it's hidden within the
SourcePackageRe
into recipe and manifest links but rather do two queries, one for
recipes referencing a branch and then one for manifests/build logs
referencing a branch. In my model code currently, there is no interface
for SourcePackageRe
SourcePackageRecipe content type.
> Or is there no need for such a distinction?
I don't really think there is.
Cheers,
mwh