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

[Peter Rabbitson]

On Thu, Sep 20, 2012 at 12:23:51PM -0700, Bill Moseley wrote:
> On Thu, Sep 20, 2012 at 4:06 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:
> 
> >
> > 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.

Can you please open an RT for this? We need to revert the code in question 
then.
 
> Still have a race condition between the multiple queries, but that's a
> separate issue and doesn't hit us that often.
> 

Can you also please open a separate RT for this?