Blocker for #635892: Create a project_package module for packaged install profiles on d.o, depends on #642112: Add a latest_security_release column to {project_release_supported_versions} and #642094: Move the code to build the query that drives project_release_find_latest_releases() into a shared helper function (or something like it)...
We're going to want to compute the update status for every release node on the site. Whenever a release is created, edited, or deleted, we'll need to recompute this status for every other release on the same branch of the same project. However, those operations happen vastly less frequently than viewing release nodes, so it makes sense to just do the computation when things change and have the status in the DB to query directly (and expose to views) instead of having to compute this on the fly all the time, especially since we're going to need PHP logic, not just a big nasty SQL query.
Once we have this status sitting in a new {project_release_nodes}.update_status column, we can do all sorts of slick things:
A) project_package module can provide a view of all releases included in a package release with their update status.
B) When viewing old release nodes or the view of all releases for a project, we could flag the releases with their current update status. This might help prevent people from downloading older releases with known problems.
Anyway, exactly how we use this data will be handled via other issues (e.g. (A) will be over at #635892: Create a project_package module for packaged install profiles on d.o or a spin-off issue from there). This issue is just about adding the new column to the {project_release_nodes} table and maintaining the status correctly.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | 642114-3.prn_update_status_views.patch | 6.93 KB | dww |
| #2 | 642114-2.prn_update_status_views.patch | 5.11 KB | dww |
| #1 | 642114-1A.prn_update_status.patch | 8.88 KB | dww |
| #1 | 642114-1B.prn_update_status.patch | 7.37 KB | dww |
Comments
Comment #1
dwwAll the blockers for this are now done. I've got this working two different ways, not sure which is the best... In both cases, we just handle adding the new 'update_status' column to {project_release_nodes} in project_release_update_6006() (from #642110: Add native support in project_release for a "Security update" term where we added the 'security_update' column) and letting the value get initialized automatically by the project_release_check_supported_versions() calls in project_release_update_6008() -- no sense doing that whole operation twice.
However, I'm not sure which approach in project_release.module makes the most sense. The problem is that to compute the update_status column, we basically need to do the same query we do down in project_release_find_latest_releases(), we just need to process the results a little differently. So, here are the two options:
A) Add a separate function called project_release_compute_update_status() which we invoke at the end of project_release_check_supported_versions(). In some ways, it makes the code a lot clearer and it's easier to document what's going on. However, it also duplicates some work, and we end up running the fairly expensive query twice. It shouldn't matter *that* much since create/update/delete on release nodes happens quite infrequently, and we might even be saved by the MySQL query cache or something.
B) Add a flag to project_release_find_latest_releases() so that it knows we want to fix the update_status column for all the releases on the branch while we're searching for the latest and recommended releases. This way, we only do the query once, but it's a little weird to have this side effect where searching for the latest and recommended releases can also update the update_status records if you want it to.
I've tested both, and they're both working great. Just not sure which is actually the better choice for keeping the code clearer. I could make arguments both ways. Anyone have a strong opinion?
Thanks!
-Derek
Comment #2
dwwRegardless of 1A vs 1B, this patch adds initial views support for the update_status field.
Comment #3
dwwNow with optional support for displaying the status via the watchdog icons, not just text.
Comment #4
dwwEarlier in IRC (before there was any code), hunmonk thought (A) would be better. I just posted both to actually see how bad each option was. I just asked webchick in IRC, and she agreed that (A) was better, even if it's slightly less efficient. If it actually becomes a problem on d.o, we can always revisit/refactor.
So, I committed #1A to HEAD. I also committed #3 for basically full views support for this field. Yay!
Back to #635892: Create a project_package module for packaged install profiles on d.o at long last... ;)
Comment #5
hunmonk commentedfound one small bug in the doxygen for project_release_compute_update_status():
pretty sure it doesn't use timestamps anymore, but the version_weight setting, then alphabetical DESC, right?
Comment #6
dwwGood catch, thanks. FYI: it's "version_extra_weight", not "version_weight", and then it's just "version_extra" alphabetical. Committed a fix to HEAD: http://drupal.org/cvs?commit=294584