Bug #61740 for Tree: add_child() behaviour is erratic

Tue Sep 28 23:37:14 2010 RSAVAGE [...] cpan.org - Ticket created

Subject:

add_child() behaviour is erratic

Hi Folks For a tree which has never been serialized to disk, or has been cloned, add_child(Tree -> new(...) ) and add_child({at => $i}, Tree -> new(...) ) both work. For a tree written to disk, or read from disk, the first form works, but the second form dies with: Can't call method "LEVEL_ORDER" on unblessed reference at /home/ron/perl5/lib/perl5/Tree/Persist/DB/SelfReferential.pm line 104. The line in question is: my $traversal = $tree->traverse( $tree->LEVEL_ORDER ); When {at => $i} is used, line 150 calls _create() with a hash which is not blessed into the Tree class. I haven't figured out yet why that is, but I have a demo which invariably fails at this point, so I'm looking in to it.

Wed Sep 29 01:24:39 2010 RSAVAGE [...] cpan.org - Correspondence added

Hi Folks The problem is line 119 of Tree.pm: $self->event( 'add_child', $self, @_ ); If I change this to: $self->event( 'add_child', $self, @nodes ); my code works as expected. But then, the {at => $i} options are not passed in. Are they needed? The other way to fix it is, restore line 119, and patch Tree::Base. In this, add a copy of sub _strip_options from Tree, and patch _add_child_hander and _remove_child_hander, thus: Change: my ($parent, @children) = @_; push @{$self->{_changes}}, { to my ($parent, @children) = @_; my $opt = $self->_strip_options(\@children); push @{$self->{_changes}}, { Presumably {at => $i} does not have to be passed in to the add/remove child handlers, so the first patch is better. Agreed?

Wed Sep 29 01:24:45 2010 RSAVAGE [...] cpan.org - Status changed from 'new' to 'open'

Mon Oct 08 19:38:27 2012 RSAVAGE [...] cpan.org - Correspondence added 120 min

Hi This is fixed by using my patches to Tree::Persist V 1.01. Unfortunately, this latter version is not yet on CPAN because of a problem making me (Ron) co-maint of Tree::Persist.

Mon Oct 08 19:38:28 2012 RSAVAGE [...] cpan.org - Status changed from 'open' to 'resolved'

Mon Oct 08 19:38:28 2012 RSAVAGE [...] cpan.org - Given to RSAVAGE