On Mon, Oct 4, 2010 at 8:22 AM, Ronald J Kimball <[email protected]>wrote:
> On Sat, Oct 2, 2010 at 8:16 PM, Bill Moseley <[email protected]> wrote: > >> Seems like ->single (and thus find_or_create) should throw an exception if >> more than one row is returned, columns passed to find_or_create must satisfy >> a defined unique constraint, and if a single row is found any non-constraint >> columns specified should be updated. >> > > find_or_create() should not update an already existing row. That's what > update_or_create() is for. > Yes, I confused that in my email. And, indeed there's been a few places in our app where find_or_create was used instead of update_or_create() when additional columns were provided and expected to be updated. Have to watch for that. Looking at our database logs I can see where some duplicate key issues have been real race conditions, but the more significant issues of this type seem to be related to the find/update_or_create call not agreeing with the columns defined in add_unique_constraint() and then falling back to using all columns in the find() and then either returning no rows or multiple rows. Again, what I'm currently doing is turning any warning into an error within find() (specifically to catch the warning about returning multiple rows) and then also throwing an exception if the _unique_queries method returns nothing to prevent falling back to searching on all columns provided. Running tests with those two changes found a few places where code needed to be fixed. After testing with those changes I'll see if the duplicate key issues still present under load. -- 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]
