On Mon, Jun 21, 2010 at 11:54 PM, Robert Collins <[email protected]> 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 <[email protected]> http://www.stuartbishop.net/ _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
