Michael Bayer ha scritto: > > On Feb 22, 2007, at 1:14 PM, Manlio Perillo wrote: > >> Michael Bayer ha scritto: >>> >>> On Feb 22, 6:04 am, Manlio Perillo <[EMAIL PROTECTED]> wrote: >>>> Michael Bayer ha scritto: >>>> >>>>> its what it says...its updating the database and not finding the >>>>> rows >>>>> it expects, indicating some other concurrent process already >>>>> deleted >>>>> that row. >>>> Is this actually possible, even if each query run in its own >>>> transaction? >>>> The database is Postgresql 8.1, Debian Etch. >>> sure...its a deleted row so row locking doesnt even count....both >>> transactions can occur totally separate from each other too. >>> >> Ok, but then why SQLAlchemy raises an Exception? >> > > because the second transaction tried to do something, like delete a > row, and the row wasnt there....some other transaction already got to > it. therefore the operation failed. this is just basic "optimistic > concurrency checking". >
The problem is the operation is not failed. All the rows that must be delete have been deleted. Suppose I'm going to delete 10 rows, and got a count of 8 rows. If SQLAlchemy raises an exception, the transaction will be rolled back and 8 rows will not be deleted at all. I'm really not sure about the right thing to do here. Regards Manlio Perillo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
