[Dbix-class] find_or_create and unique constraints

Bill Moseley moseley at hank.org
Mon Oct 4 15:44:24 GMT 2010


On Mon, Oct 4, 2010 at 8:22 AM, Ronald J Kimball
<rkimball at pangeamedia.com>wrote:

> On Sat, Oct 2, 2010 at 8:16 PM, Bill Moseley <moseley at hank.org> 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 sat=
isfy
>> a defined unique constraint, and if a single row is found any non-constr=
aint
>> 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
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20101004/7fc=
430d5/attachment.htm


More information about the DBIx-Class mailing list