In the D5 version of project, when you browse by date the project nodes are returned in descending date order, based on the date of the file attached to the release node.

In working on the project browsing views for D6, this is something that's pretty tricky to get and makes both the code and the db queries fairly complicated, and makes the query slower.

Earl suggested that we add a new column to the {project_projects} table called something like "last_updated_release" which would store the nid of the release node with the most recent updated/changed timestamp. To get this working we'd need to make a few changes to the existing code in the D6 version:

1. Add this column to the {project_projects} table
2. Write an update function to project_release.install that populates this column for existing sites.
3. Modify project_release_db_save() (which is called from project_release_insert() and project_release_update()) so that it updates the value of {project_projects}.last_updated_release whenever the release node is inserted/updated. If we want to continue to base date sorting on the file date instead of the release node updated/changed date, we would only update {project_projects}.last_updated_release if the file was added or changed when the release node is saved. Therefore, modifying the release notes won't caused the changed date of the release node to change.
4. Modify the packaging script so that whenever it modifies the release node (it publishes it and fills in the file info after packaging the file) it also sets the value of {project_projects}.last_updated_release to the nid of the release node.

For sites without the project_release module enabled, they'd have an essentially worthless column, but I don't see that as being a big problem.

Then, for the views stuff, we'd still need to write a relationship handler, but it would be easy, since it wouldn't require much logic itself.

So, is this a good/bad idea? Are there things I'm missing that we'd also need to take care of to make this work? Since this will be a bit of work to do I wanted to get some feedback to see if it's worth doing.

Thanks

Comments

merlinofchaos’s picture

I'm favor of this because while it *is* de-normalized data, it is low risk data to maintain and could have significant positive performance impacts when doing views where you need to know this data.

dww’s picture

Sounds reasonable to me. It minorly complicates some code (mostly localized) in a few functions, in exchange for more simple views and queries. Especially if this will ease the load on the d.o DB, seems like a good thing.

1-3 seem pretty obvious. Re: 4 -- the only thing you'll have to touch in the packaging script is this function: package_release_update_node().

drumm’s picture

Status: Active » Closed (won't fix)

The project_projects table is no longer in D7.