This module would be AWESOME if you designed it to cache each node's set of links in it's own table so a search of related links would only have to be done when a node is created or updated. The related links could then be retrieved from the table on each view rather than do searches on each view. Even if a node did not have "related links" to nodes created after it, the value would be really fantastic. People start viewing on more recent nodes and travel backward through the node structure anyway.

The caching of data is simply critical to this module, as any site with more than about 9000 nodes has a rough time doing a full search_index table search on every page view.

Comments

spiderman’s picture

Assigned: Unassigned » spiderman
Status: Active » Needs work

I've started working on this feature, and all is going well. Jeff Eaton's post on caching has been very helpful, and the Drupal Cache API is quite straightforward. I have the basic caching mechanism in place now, and just need to add logic to flush the cache periodically, and most importantly keep the cached data fresh.

My plan for this last piece is two-pronged: implement a hook_nodeapi() function to catch node inserts/updates and recalculate the set of related nodes for these (prong 1), and then a hook_cron() implementation to scan through older nodes and rebuild the related nodesets for these to keep the relationships fresh- if a newer node is related to an older one which hasn't changed recently, the cron task should catch these.

Currently I'm thinking I'll push out a 1.1 release with a bunch of other fixes and cleanup, and then post a patch here for review before committing and rolling a 1.2 release. After that, on to D7 (finally!)

Meantime: feedback is greatly appreciated!

spiderman’s picture

Version: 6.x-1.0 » 6.x-1.1

This will be the main new feature for an upcoming 1.2 release, along with some further refactoring and at least core test coverage to smooth testing through a 7.x upgrade.