> So
>
> $photos->search({ owned_by => $uid })->find({ id => $photo_id })
>
> has to include the WHERE owned_by = $uid even if the find specifies
> key => 'primary'.
>
> However, we -can- ignore keys passed in the find hash. But I'm not sure
> we should, except in case of a *_or_* call.
>
> Thoughts, people?I personally find the behavior you described to be what I would expect. I do not think a a further link in a chained search should undo what a previous link did. Here's my thoughts: The find behavior you just described is desirable;e to me and what I would expect the software to do. If you need to remove a restriction you should build a new RS On the case of the *_or_* methods it should search just like find and, if not found use the rs values over the values passed to the sub. It just makes much more sense to me because I expect a RS create operation to create a member of that particular subset. In the case of create_or_update i see the argument towards giving higher precedence to the values passed to it over the values of the RS in the update part, but NOT in the create part. this may be unintuitive though _______________________________________________ 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]
