[Dbix-class] Unique constraint isn't good enough for update_or_create?

Sean McAfee eefacm at gmail.com
Thu Nov 12 18:59:59 GMT 2009


On Wed, Nov 11, 2009 at 10:21 PM, Darren Duncan <darren at darrenduncan.net>wr=
ote:

> Sean McAfee wrote:
>
>> I have a table that doesn't have a primary key, but does a unique index.
>>  When I call update_or_create on this table, I can create the row just f=
ine,
>> but when I try to update it with a second call, this exception gets thro=
wn:
>>
>> Cannot safely update a row in a PK-less table
>>
>> But the documentation for DBIx::Class::ResultSet explicitly says that the
>> method can use unique constraints.  So why isn't it?
>>
>
> Does your table have multiple unique constraints or just one?
>
>
Just one.


> From my quick reading, the ResultSet documentation appears to be saying y=
ou
> need to provide an explicit 'key' attribute value when a match is being d=
one
> on a non-primary key (aka unique constraint), rather than it figuring thi=
ngs
> out for itself if you have exactly 1 unique constraint.


That's not how I read it:

If no "key" is specified, it searches on all unique constraints defined on
the source, including the primary key.

I have no primary key and a single unique constraint, so there's no
ambiguity.


> Have you set 'key' explicitly?
>
>
Yes, I had to set it to get the create half of update_or_create to work.

Shortly after I posted my original message, I found a workaround: recasting
my unique constraint as a primary key.  It's a bit conceptually dirty, but
it gets the job done.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20091112/be9=
fe2da/attachment.htm


More information about the DBIx-Class mailing list