Merge lp:~mwhudson/launchpad/recipe-db-schema into lp:launchpad/db-devel
| Status: | Merged |
|---|---|
| Approved by: | Michael Hudson-Doyle on 2010-01-12 |
| Approved revision: | not available |
| Merged at revision: | not available |
| Proposed branch: | lp:~mwhudson/launchpad/recipe-db-schema |
| Merge into: | lp:launchpad/db-devel |
| Diff against target: |
300 lines (+227/-0) 6 files modified
database/schema/comments.sql (+62/-0) database/schema/patch-2207-25-0.sql (+149/-0) database/schema/security.cfg (+7/-0) lib/lp/code/doc/branch.txt (+2/-0) lib/lp/code/model/branch.py (+1/-0) lib/lp/registry/model/person.py (+6/-0) |
| To merge this branch: | bzr merge lp:~mwhudson/launchpad/recipe-db-schema |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Stuart Bishop | db | 2009-12-17 | Approve on 2010-01-12 |
| Jonathan Lange (community) | 2009-12-17 | Approve on 2010-01-10 | |
|
Review via email:
|
|||
Commit Message
The database tables for the SourcePackageRecipe build work.
| Michael Hudson-Doyle (mwhudson) wrote : | # |
| Muharem Hrnjadovic (al-maisan) wrote : | # |
Hello there!
I understood that manifests need to store the revision for each referenced branch. I don't see that detail addressed in the schema change. Or did I miss something?
| Muharem Hrnjadovic (al-maisan) 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 SourcePackageRe
Or is there no need for such a distinction?
| Michael Hudson-Doyle (mwhudson) wrote : | # |
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 SourcePackageRe
I guess I was expecting that you wouldn't do a big query for all
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
| Michael Hudson-Doyle (mwhudson) wrote : | # |
Muharem Hrnjadovic wrote:
> Hello there!
>
> I understood that manifests need to store the revision for each referenced branch. I don't see that detail addressed in the schema change. Or did I miss something?
Oh whoops, forgot about that.
I think I'm gradually coming around to Jono's view that we'll have
fairly structured storage of the recipe in the db, so all this will
probably change quite a bit before we start using it in anger.
Cheers,
mwh
| Stuart Bishop (stub) wrote : | # |
I'm curious why SourcePackageRe
If this is a 1:1 relationship, do you have a rationale for this being a separate table?
If this is not a 1:1 relationship, how do we express this in English? A SourcePackageRecipe contains multiple recipes?
I'm happy to have the non-structured recipe column provided we don't need to do anything with it besides store it, retrieve it, and send it to builders. If the appservers need to decode it we should consider a more structured format per Jono's reported views.
SourcePackageBu
The SourcePackageRecipe unique index does not match its name. Do you want (owner, distroseries, sourcepackagename, name) unique or just (distroseries, sourcepackagename, name)? I prefer ALTER TABLE ADD CONSTRAINT sourcepackagere
It is going to need more indexes - pretty much every foreign key constraint needs an index on that column. I can add these in later if you want. We also will probably need indexes on SourcePackageBuild and SourcePackageBu
| Jonathan Lange (jml) wrote : | # |
Michael and I had a chat on the phone. We've worked out a schema that will have a much more structured view of recipes. Should be up for review again tomorrow.
| Michael Hudson-Doyle (mwhudson) wrote : | # |
Hi guys, I think the patch is now ready and we'd like to land it before It will still need indexes added, but I hope stub can do that :-)
| Jonathan Lange (jml) wrote : | # |
* 'name' on SPRInstruction should be NOT NULL, I think.
* You _could_ add a constraint saying that the line number should be strictly greater than the parent's line number. Not sure if this is necessary.
* Shouldn't SourcePackageBu
Other than that, looks good.
| Michael Hudson-Doyle (mwhudson) wrote : | # |
* OK.
* Doesn't seem useful really
* OK.
Go again?
| Stuart Bishop (stub) wrote : | # |
Allocated patch number is patch-2207-25-0.sql
SourcePackageRe
The sourcepackagere
sourcepackagere
Please change:
ALTER TABLE SourcePackageRe
ADD CONSTRAINT sourcepackagere
UNIQUE (line_number, recipe_data);
into the more useful to PostgreSQL variant:
ALTER TABLE SourcePackageRe
sourcepackagere
UNIQUE (recipe_data, line_number);
sourcepackage is one word in Launchpad, so the .*source_package.* columns
need to be renamed .*sourcepackage.*.
As discussed on IRC and seen at http://
Needed indexes:
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
--CREATE INDEX sourcepackagere
--ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagebu
ON SourcepackageRe
| Stuart Bishop (stub) wrote : | # |
I missed some indexes and one of the constraints is wrong.
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
CREATE INDEX sourcepackagere
ON SourcepackageRe
Should BuildSourcepack
ALTER TABLE BuildSourcepack
buildsourcepack
Otherwise:
CREATE INDEX buildsourcepack
ON BuildSourcepack
One of the constraints is wrong (NULL != NULL in SQL 3-value boolean). Drop:
ALTER TABLE SourcePackageRe
sourcepackagere
UNIQUE (sourcepackage_
Replace with:
CREATE UNIQUE UNDEX sourcepackagere
ON SourcepackageRe
WHERE sourcepackage_
CREATE UNIQUE INDEX sourcepackagere
ON SourcepackageRe
WHERE sourcepackage_

Hi there,
This branch adds the db schema for sourcepackagere cipes and associated things that was much discussed on the list. I've written a little code using this schema now (see lp:~mwhudson/launchpad/recipe-model-code) and it still feels more or less right and I would like to start landing code, so now seems like a good time to get this branch formally reviewed.
This presupposes a fairly boring way of representing recipes in the database -- but I think that this will be easier to change if we want to later.
Cheers,
mwh