DBIx-Path

 view release on metacpan or  search on metacpan

lib/DBIx/Path.pm  view on Meta::CPAN

    }
    $memo{$me->id}=\@ret;
    return @ret;
}
}


=head3 list

    @nodes=$node->list()

Returns an unordered list of nodes which are children of the current node.

This method does not operate recursively; the DBIx::Tree module would be more
appropriate for that purpose.

=cut

sub list {
	my($me)=@_;
	my @ret;
	local $_;
	
    $me->_lock('r');
	$me->{sth}{list}->execute($me->{id});
    $me->_unlock('r');
	push @ret, $me->_row_to_obj($_) while $_ = $me->{sth}{list}->fetchrow_arrayref;
	return @ret;
}

=head2 Accessors

=head3 id

    $id = $node->id()

Returns the ID of the current node.

=head3 pid

    $pid = $node->pid()

Returns the parent ID used to resolve the current node.  Returns C<undef> for
the root node.

=head3 name

    $name = $node->name()

Returns the name used to resolve the current node.  Returns C<undef> for the
root node.

=cut

for my $field qw(id pid name) {
	no strict 'refs';
	*{$field}=sub { $_[0]->{$field} }
}

{
    my $locked=0;
    sub _lock {
        my($me, $type)=@_;
        $locked++;
        if($locked == 1 and $me->{hooks}{lock}) {
            $me->{hooks}{lock}->($me->{dbh}, $type);
 	    }
    }
    sub _unlock {
        my($me, $type)=@_;
        if($locked == 1) {
            $me->{hooks}{unlock}->($me->{dbh}, $type) if $me->{hooks}{unlock};
		}
        elsif($locked == 0) {
            croak "DBIx::Path: PANIC: Key won't fit in lock";
		}
        $locked--;
    }
    END {
	    if($locked) {
            warn "DBIx::Path: WARNING: Program may have exited with lock(s) still held";
		}
    }
}

sub _row_to_obj {
	my($id, $pid, $name)=@{$_[1]};
	(ref $_[0])->new(%{$_[0]}, id => $id, pid => $pid, name => $name);
}

=head2 Diagnostics

DBIx::Path primarily communicates errors to the caller by returning C<undef>
and setting $! to an appropriate value.  However, it does throw a few
exceptions.

=over 4

=item C<Invalid or missing %s>

One of the required parameters to C<new> (either the database handle
or the table name) was omitted, or something that clearly wasn't a handle or
table name (such as an C<undef> value) was passed.  Please check your code.

=item C<< DBIx::Path->new: Couldn't prepare '%s' statement: %s >>

C<new> prepares several SQL statements which are used by the other
methods.  This message indicates that the indicated statement was invalid.
This could indicate a bad table name or invalid I<whatever>_column settings;
it could also mean that the SQL used by DBIx::Path isn't recognized by your
DBD.

Check the parameters you're passing to DBIx::Path->new, then make sure the
SQL at the indicated line number is valid for your server.  The text after
the second colon is the DBI error message.

=item C<DBIx::Path: PANIC: Key won't fit in lock>

Internal error indicating that DBIx::Path wanted to call your unlock hook,
but somehow forgot to call your lock hook in the first place.  This shouldn't
happen.

=item C<DBIx::Path: WARNING: Program may have exited with lock(s) still held>

DBIx::Path has an internal variable tracking how deeply nested locks currently
are; it uses this to ensure that your lock/unlock hooks are only called once
per method.  This message will be printed to STDERR if that variable has a 
non-zero value when Perl exits; it indicates that you should check to make sure
your database hasn't become wedged.

This message is most often seen when an error occurs within DBIx::Path itself;
it may also be displayed for particularly nasty sorts of bugs within DBIx::Path
or if your process is hit by a signal while DBIx::Path is querying your 
database.  It's never good news.

=back 4

=head1 BUGS AND ENHANCEMENTS

There are no known bugs at this time; however, I'm not that experienced



( run in 2.543 seconds using v1.01-cache-2.11-cpan-39bf76dae61 )