The current db schema maps each "project" to a single "origin" (while keeping the history of this mapping).
This prevents us from having a single project point to, e.g., a tarball directory and a git/hg repository at the same time.
Do we want to register that Python-3.5.0.tar.xz is different to the 3.5.0 tag on hg.python.org?
| rDSTO Storage manager | |||
| rDSTO5c2a6fc2dc6b sql: update schema of organizations and projects | |||
| rDOBJS Object storage | |||
| D67 | rDOBJSefe2dc312611 sql: update schema of organizations and projects | ||
I've had some thoughts about this problem, and here are my propositions.
The most flexible way to store the Project to Origin mapping is a three-way map:
The idea is that each project can be hosted by different organizations, and that we can map those together.
In our current schema, we should create one organization per way of listing importable artefacts :
Each github repo would be one project. Forks would be associated to the same project, but with another organization (or even the same organization but a different origin).
Each debian source package name would be one project too, and be associated with two origins (if applicable), one for the snapshot.d.o organization, and one for the archive.d.o organization.
We then need a way to "deduplicate" projects (and for instance associate debian's python-hy with github's hylang/hy). My opinion on this is to leave the "automatically generated" projects alone, and to keep a separate "association table" that would be filled separately.
Mulling this over, this could be a bit different:
We probably need to add an "autogenerated" flag to organizations, and a "matching" table like we do for projects.
@zack points out that organization does not feel like the right term anymore.
Possible alternatives :
We will also need to define an entity typology