On Mon, Oct 4, 2010 at 8:58 AM, Zbigniew Lukasiak <[email protected]> wrote:
> Just a warning. In the general case there can be conditions in the > resultset - for example if you use find_or_create on a related result > - (or if you are using find_or_create_related ) then the whole thing > becomes more complicated. > Yes, I'm aware of that, but certainly do not understand all the possible situations. How I mitigated was to ignore the case when no additional criteria is provided. If a criteria is provided but _unique_queries does not return any queries then I warn -- assuming no unique query could be determined. The situation I want to avoid is where a find() returns more than one row -- which DBIC will warn about, but also where no rows are returned because no unique keys are determined so DBIC falls back to doing a select with all the passed-in criteria. That could would return no rows when a row with a unique key exists and then return in a duplicate key error on insert. Again, what I'm attempting to do is find our incorrect usage of find-like methods (and incorrect unique constraint configuration) in our code. Two issues I'd like to see discussed here is if DBIC should throw an exception if find() returns more than one row (instead of a warning), and if it makes sense to fall back to the full criteria passed to find() if no unique key can be determined. Thanks, -- Bill Moseley [email protected]
_______________________________________________ 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]
