[drupal-devel] [bug] Make node_save() recursion-aware

[puregin]

On 18 Aug 2005, at 4:48 PM, Todd Grimason wrote:

> Sorry if this isn't the right etiquette - I have a question(s) about
> this issue which didn't seem right to clutter up the "official" issue
> comments with:
>
> Why is node_save() called before the insert/update event fires (called
> via nodeapi) and not after? It seems a bit arbitrary.
>
> I guess there are situations where you don't want to fire that  
> until the
> node is saved, but that would seem to preclude anything else from
> modifying that node without having to save it again. Was this a  
> decision
> to be a bit more simple and accept the requirement of other modules
> having to re-save if they want to modify the node itself, and not just
> affect other things?
>
> Maybe what's needed is this:
> http://api.rubyonrails.com/classes/ActiveRecord/Callbacks.html
>
> Well I'm sorta joking, but the key thing here is as far as I can see
> (not very, I'm fairly new to the deep internals of drupal) is having a
> distinction between pre- and post-save  [aka insert/update], since "on
> save" is ambigious isn't it? (well in name at least, the actual  
> behavior
> in this case it appears to actually be a "post save" event, right?).

   I think that this is a very good point. I ran into something
similar to this while working on HTML export for books - here
the nodes were part of a tree, and children needed to be
processed in the course of processing a node.

   In my situation, I implemented a function to traverse the
structure - it accepts callbacks called at the start of a
node visit and and the end.

   I think a similar approach would work for other structures.  The
problem of having nodes tracking how often they are visited
is that the node can't (shouldn't) know about any context
or global structure it appears in.

   So, I agree with Dries - having to save this kind of state
in a node is an indication that something is wrong with
the design.

> Until I followed all the calls around, I assumed the callbacks had a
> chance to run before node->save was actually called -- like everyone
> gets to do their thing before the node is stored away in the DB -- but
> now I see you actually gotta use your copy and stick it in the  
> database
> yourself, basically overwriting the core functionality -- so  
> potentially
> you could have 0..* saves in response to the insert/update callback,
> yes?
>
> Am I anywhere near understanding what's going on here?
>
>
> -- 
>
> ________________________________
> toddgrimason*todd[ at ]slack.net
>
>
puregin

http://www.puregin.org