[Dbix-class] Providing extra limitations to query

[Rob Kinyon]

On Tue, Jan 10, 2012 at 08:49, Will Crawford <billcrawford1970 at gmail.com> wrote:
> $rs->search( \%implicit_params )->search( ... stuff passed into your
> function ...);
>
> I've occasionally done this more overtly by having a ->with_filter_X
> method on the result set, and called it like
> $foo_rs->with_melitta->search( \%user_supplied_params ) ... good
> examples would be where you have, say, a "deleted" flag column and you
> must only search in non-"deleted" records.
>
> On 10 January 2012 13:03, Dmitry Belyavsky <beldmit at gmail.com> wrote:
>> Greetings!
>>
>> I have a function similar to
>>
>> my $account_id = shift;
>> my $query_params = shift;
>>
>> my $rs = $schema->result("Table")->search($query_params);
>>
>> I want to provide account-related access restrictions implicitly so I
>> need to modify the $query_params variable. There are no problems when
>> the $query_params is a hash reference, the code looks like
>>
>> my $params = {-and => [$query_params, {restrictions} ]}
>> my $rs = $schema->result("Table")->search($query_params);
>>
>> How can I do it in case of the array ref passed as original params?
>> Thank you!

The key to remember here is that ->search() doesn't actually search
anything - it's a constructor that builds a resultset from another
resultset. A resultset is not a search. It's all the information
necessary to build the various clauses that would go into a search.

$schema->result("Table") returns a $rs that maps to the SQL "SELECT *
FROM Table". When you do $rs->search({ foo => 1 }), you're really
saying "Given the
 original conditions (if any) on $rs, construct another resultset
object that has all of those PLUS 'foo = 1'."

This is called "resultset chaining."
-- 
Thanks,
Rob Kinyon