launchpad-dev team mailing list archive

[Stuart Bishop <stuart.bishop@xxxxxxxxxxxxx>]

On Mon, Jun 21, 2010 at 11:54 PM, Robert Collins
<robert.collins@xxxxxxxxxxxxx> wrote:
> Julian, can we add a DB constraint to enforce the row count?
> alternatively, can we change the processor to handle having duplicate
> rows. If we can either ensure the data has the required shape for the
> whole stack, or change the shapes that we accept to be more tolerant,
> then the issue should no longer affect us - and, in either direction,
> prevent variations-on-a-theme for that table (assuming you look for
> similar problems while you are in the area.

If we can add a DB constraint, everything should just work - one of
the transactions will raise an integrity error, causing the
transaction to be retried which (if the form is good) render an error
message. The other transaction will just complete.

> Gary - thats the same way I'd test something like this - step through
> the concurrency issue by hand; doing it at the browser level is really
> hard :) - and worth noting I think that as we have many app servers,
> and front ends, doing it in the real world is even harder.

Generally you don't. We already have tests that integrity errors cause
the transaction to retry. We should already have a test showing the
form generates a nice error message to the user if a duplicate exists
at the start of the transaction. Together these assert things work
correctly.

Assuming the form is correct, the issue here is a form asserting some
constraint that is not backed by the database constraints. The
appservers cannot resolve this.

-- 
Stuart Bishop <stuart@xxxxxxxxxxxxxxxx>
http://www.stuartbishop.net/