Jason Gottshall wrote:
David Ihnen wrote:
So in the wake of fREW showing a modification of the classes to allow
the modification of the delete, I utilized a corrollary concept...
restricting a result set automatically/transparently, as you would in
case of that delete - not normally showing the deleted rows. In my
case, my alerts table has a possible action window, possibly has been
dismissed, and possibly might be inactive. This made the resultset
class more complicated, but not unmanageable. It was fun to work
through the logic of modifying an arbitrarily complex requested
search clause. If you specify values for these, it is assumed you
know what you're doing and this result set class won't further modify
the terms. I may have missed the handling of already defined
alert_expire terms though... maybe I should make it inactive if you
specify any of the terms anywhere in the \%where tree.
package DB::Schema::active_alert_resultset;
use base 'DBIx::Class::ResultSet';
sub search {
my $self = shift;
$_[0]->{'inactive'} ||= 0;
$_[0]->{'dismissed'} ||= \"IS NULL";
$_[0]->{'alert_time'} ||= { '<' => \"NOW()" };
my $aeor = [];
push @{$aeor}, { alert_expire => { '>' => \'NOW()'} };
push @{$aeor}, { alert_expire => \'IS NULL' };
if ($_[0]->{'-or'}) { # If there is already an -or, we need to
nest it into an -and
# so we don't overwrite the term, or change
the logic by orring with it.
my $and = $_[0]->{'-and'} ||= []; # Use an existing -and term
if already supplied.
push @{$and}, { -or => delete $_[0]->{'-or'} }; # Move the old -and
push @{$and}, { -or => $aeor }; # add our alert expire or term
} else {
$_[0]->{'-or'} = $aeor;
}
return $self->next::method( @_ );
}
You're only checking to see if the given columns have specified values
passed in, but what if ->search was called on a resultset object that
*already* has constraints for these columns?
What? How can you be in a result class and not in it too? Can you give
an example of how to write that in code?
Until DBIC goes Moose, it's tricky (and not very safe) to introspect
an existing RS to see what's already been done to it...
If I have already restricted the resultset, then re-restricting it by
the same terms will filter out whats not there, right? And asking for
dismissed => \'IS NOT NULL' on an alerts (or derived) resultset will
always give you empty set. No active alerts have dismissed NOT NULL
David
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
