[Dbix-class] Tracking "parent" resultset.

[Bill Moseley]

In another thread about chaining resultsets and keeping previous sets around
for testing Matt noted:

... if you keep all the intermediate resultsets around in the stash or

wherever (or better still refactor to resultset methods and have your

custom resultset class keep the intermediate resultsets around) then it

seems like it should be pretty easy to walk back up the chain making

the extra queries until one returns data - at which point you know the last

step you walked back up is the problem child for this request.


Ok, it's a foggy Sunday morning I'll give that a try.

In review, what I want to do is:

$rs =3D $schema->resultset( 'Cd' );
$rs =3D $rs->search( { year =3D> 2010 }, { comment =3D> 'Year not 2010' } );
$rs =3D $rs->search( { position =3D> { '>', 5 }}, { comment =3D> 'None more=
 than
5th position' } );
$rs =3D $rs->search( { deleted =3D> 0 }, { comment =3D> 'None deleted' } );

$failed_commet =3D $rs->reason_failed if $rs =3D=3D 0;

In other words, have each $rs know its parent result set and be able to walk
up (or down, might be faster) the list of result sets to find out what
condition returned no results.

Is this a safe-n-sane approach for tracking parents?  Does result_rs catch
all times a new $rs might be created?  Or do I need to override new()?

In my ResultSet base class:

has 'parent' =3D> ( is =3D> 'rw' );
has 'comment' =3D> ( is =3D> 'rw' );

around 'search_rs' =3D> sub {
    my ( $orig, $rs, $cond, $attr,  @rest ) =3D @_;

    my $comment =3D delete $attr->{comment};

    my $new_rs =3D $rs->$orig( $cond, $attr, @rest );

    $new_rs->parent( $rs ) if $rs->{cond};
    $new_rs->comment( $comment ) if $comment;

    return $new_rs;
};


-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20100516/2d7=
b2967/attachment.htm