[Dbix-class] Fun with auto-restricted result sets

[David Ihnen]

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