Merge lp:~stevenk/launchpad/db-spph-ancestry into lp:launchpad/db-devel
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Steve Kowalik on 2010-12-02 | ||||
| Approved revision: | no longer in the source branch. | ||||
| Merged at revision: | 10030 | ||||
| Proposed branch: | lp:~stevenk/launchpad/db-spph-ancestry | ||||
| Merge into: | lp:launchpad/db-devel | ||||
| Diff against target: |
172 lines (+48/-7) 7 files modified
database/schema/comments.sql (+2/-1) database/schema/patch-2208-34-0.sql (+8/-0) lib/canonical/launchpad/interfaces/_schema_circular_imports.py (+3/-0) lib/lp/soyuz/interfaces/publishing.py (+9/-1) lib/lp/soyuz/model/publishing.py (+7/-2) lib/lp/soyuz/tests/test_publishing.py (+17/-2) lib/lp/testing/factory.py (+2/-1) |
||||
| To merge this branch: | bzr merge lp:~stevenk/launchpad/db-spph-ancestry | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Jonathan Lange (community) | 2010-12-01 | Approve on 2010-12-02 | |
| Stuart Bishop | db | 2010-12-01 | Approve on 2010-12-02 |
| Jeroen T. Vermeulen (community) | code | 2010-11-26 | Approve on 2010-12-01 |
|
Review via email:
|
|||
Commit Message
[r=jml,
Description of the Change
Add an ancestor attribute onto SourcePackagePu
At the moment, nothing makes use of this field, but I wanted to get it into this months rollout.
| Jonathan Lange (jml) wrote : | # |
Two questions:
* "parent" is a more common term for "immediate ancestor". Why not use that?
* In previous discussions, I'd heard mention of a DAG model for ancestry, rather than a simple tree model. Why did you decide to go with the tree?
Thanks,
jml
| Steve Kowalik (stevenk) wrote : | # |
The original implementation for this idea was going to be a new table called 'SourcePackageA
The purpose of this field is not model the ways that packages relate to another one in a definitive way, its original intent was to allow us to traverse back up the tree to see the highest common version for the derivation work.
| Jonathan Lange (jml) wrote : | # |
OK. I strongly recommend renaming to 'parent' then, in order to be clearer.
I don't really get your second answer. You are using a tree rather than a DAG because you want to traverse back up the tree to see the highest common version. Why do you want to do that? It also doesn't answer the question about what happened to the discussion about using the DAG model.
| Steve Kowalik (stevenk) wrote : | # |
Because using a DAG for this purpose is, I believe, over-engineering the problem. We aren't using this to keep track of how publishing records relate to one another (for example, tracking copies between pockets in the Ubuntu archive, or between PPAs) -- for that we certainly would require a DAG. We are using a tree to model versioning information between publishing records.
For example:
foo (1.4-1ubuntu1) [lucid] --- foo (1.4-1ubuntu1) [karmic] --- foo (1.3-2) [jaunty] --- foo (1.2-1ubuntu1) [intrepid]
In this case, both of the parents for the publishing records for foo in both lucid and karmic would point to the jaunty version, and the parent of the jaunty version would be the version in intrepid.
As for your question for why we want to do this, I shall extend my example with this tree from the versions of foo in Debian:
foo (1.4-1) [unstable] --- foo (1.4-1) [testing] --- foo (1.3-2) [stable]
One of the issues we need to solve for derived distributions is to find the base version -- that is, the point where the packages diverged. Using the two examples together, we can see that the version of package in jaunty and stable are equal, and use that to draw out the changes made in Debian, and the changes made in Ubuntu and the changes made upstream, and are able to present these to the user.
| Steve Kowalik (stevenk) wrote : | # |
And a further comment, ancestor and ancestry is already in widespread use throughout the Soyuz codebase, so I'm keeping that up.
| Stuart Bishop (stub) wrote : | # |
I suspect we will need an index too or we will be sorry. It won't be used for the primary use case, but deleting spph records or traversing to child records will be painful without it.
CREATE INDEX sourcepackagepu
patch-2208-34-0.sql
| Julian Edwards (julian-edwards) wrote : | # |
> OK. I strongly recommend renaming to 'parent' then, in order to be clearer.
>
> I don't really get your second answer. You are using a tree rather than a DAG
> because you want to traverse back up the tree to see the highest common
> version. Why do you want to do that? It also doesn't answer the question
> about what happened to the discussion about using the DAG model.
Source ancestry is a strong meme in the Soyuz code. I'd much rather the name was consistent with that than introducing a new name for the same concept.
| Jonathan Lange (jml) wrote : | # |
Thanks for the reply Steven.
I agree it's better to keep consistency with the existing bad name than introduce a new concept.

Nicely put!
The code looks good to me. Just a few points:
Looks like it was impossible to set the right schema for ancestor in lib/lp/ soyuz/interface s/publishing. py (diff line 49), so you had to set it to mere Interface instead. When you do that, fix things up in lib/canonical/ launchpad/ interfaces/ _schema_ circular_ imports. py.
Also in lib/lp/ soyuz/interface s/publishing. py, diff line 61/62, the new parameter to newSourcePublic ation defaults to None but the method definition in the interface does not reflect that.
In lib/lp/ soyuz/tests/ test_publishing .py, I don't suppose TestSPPHModel could get away with a lighter test layer such as ZopelessDatabas eLayer? Probably not, but always nice to save a dozen seconds or so on test setup when you can.
Jeroen