[Dbix-class] DBIx::Class::Ordered changes.

[Bill Moseley]

On Thu, Sep 20, 2012 at 4:06 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wro=
te:

>
> The reason Bill started this thread is that the above apparently did not
> work for him. I am now confused...
>

Hi Peter,

Running the new update (using BETWEEN) fails, but not always.   According
to #postgresql the UPDATE is atomic (single transaction) but the constraint
is checked for every row within the atomic update.  Which is why it needs
to be deferred.

I wrote some tests where I added a large number of rows, then deleted and
could not get it to fail.  So, my assumption is the order of how the rows
are processed is not determined (not too unlike "keys %hash").   And since
it's in a single UPDATE I have no idea of the order of processing that
actually happens other than the dup key error.

We are using Postgresql 8.4.5, and the DEFERRABLE constraint for this
wasn't added until 8.5, apparently:
http://www.depesz.com/2009/08/11/waiting-for-8-5-deferrable-uniqueness/

So, we cannot make the UNIQUE constraint DEFERRABLE INITIALLY DEFERRED.
 And we also cannot just drop the contraint, it turns out, because we have
some javascript that uses the "position" value as a unique key (oops).

Thus, I overrode the new DBIC approach with the old behavior which
addresses our current problem.

Still have a race condition between the multiple queries, but that's a
separate issue and doesn't hit us that often.




-- =

Bill Moseley
moseley at hank.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20120920/a6f=
8a8db/attachment.htm