#3884 Update root's updated_by anytime any node in the tree is updated

[kleintom]

This is so that when we display a list of keys by root nodes, the updated_last data in the root reflects the entire tree. (Of course this means now you won't always know when the metadata of a key was last updated.)

A couple notes on the location of the new callbacks:

• self.root is undefined in after_destroy and even in before_destroy if before_destroy is placed after the has_closure_tree declaration (suggesting whatever clears root on self happens in has_closure_tree's before_destroy).

• self.root is undefined in after_save and all tests fail (on creating leads) unless after_save is placed after has_closure_tree (suggesting that root is set on a lead in has_closure_tree's after_save).

[mjy]

@kleintom Sorry, I should have chimed in on this earlier. Our design here is that "Housekeeping" only changes when the record changes, there are no cascading updates like this intended. This particular case then becomes a display/UI issue, find the latest data of self_and_siblings and render it.

[kleintom]

Sorry, I should have chimed in on this earlier.

No problem.

there are no cascading updates like this intended

I'm fine with making the changes, but just to make sure I'm thinking of this right: that will make displaying a list of all keys with housekeeping info considerably more expensive, right? We'll have to query every lead node in the database every time.

Paging would help, but not in the case of the Recent updates list at /leads/, where again we'd need to query every lead node in the database to figure out the n most recently edited keys.

Also there will be no record of an update if a couplet was deleted from a key.

Does that sound okay, or any other thoughts?

[mjy]

that will make displaying a list of all keys with housekeeping info considerably more expensive, right? We'll have to query every lead node in the database every time.

Yes and no. p.root_taxon_name.self_and_descendants.maximum(:updated_at) is 1/2 second for > 84k descendants, our keys will not be anywhere close to that size.

Also there will be no record of an update if a couplet was deleted from a key.

Understood. If we want to capture this we'll want to add a new attribute on Lead. This brings in the concept of Versioning etc., which is good to think about, but I'm personally not super concerned about it at the moment, and if we do want to introduce this concept I'd like to do it with a generalized approach/concern that could be re-used.