Based on and ideally developed in parallel with issue #216373: Major issue #2: Direct hook access to the query, versioncontrol_project should record the project nids for each operation in the database as long as the operation is associated to any project. On the one hand, that will improve performance (joining nids is less expensive than matching path strings), and on the other hand that makes it possible to keep operation/project association even if the project moves to another repository location. On the third hand, it will make migration from cvs.module more straightforward as that module also keeps track of the nid in its database schema.
Implementing this requires three simple steps:
- Introduce a new table {versioncontrol_project_operations} with columns (vc_op_id, nid) which also form the primary key together.
- Implement hook_versioncontrol_operation() to store the nids for each operation. The nids can be found out with versioncontrol_project_get_projects_for_operation().
- Write an update function that performs the operation/nid association retroactively for all existing operations in the database (versioncontrol_get_operations()).
When that is done, implementing the hook provided by #216373: Major issue #2: Direct hook access to the query is going to be trivial.
Comments
Comment #1
jpetso commentedProbably a project/item association would be more correct than a project/operation association. Therefore, going for {versioncontrol_project_items} instead of {versioncontrol_project_operations}.
Comment #2
jpetso commentedActually, I'll do both. One canonical table with project/item associations, and a cache table (regeneratable from the former) with project/operation associations, for nicely performing queries ("View commits for project $x", which is used all over the place on d.o for example).
Comment #3
jpetso commentedDone, committed in commit 170598.