On Wed, 2009-02-25 at 23:09 -0500, Karen Tracey wrote: > You want to use the transaction commit/rollback routines, not cursor > ones: > > http://docs.djangoproject.com/en/dev/topics/db/transactions/
I did not know about this. > > > I think that the cursor should rollback if there is an error > and then > throw the exception. Thats a more reasonable behavior than > what we > have right now. > > Except rollback isn't the only option, from what I read. Though I > have never experimented with it, apparently your code could also > choose to commit the transaction at this point. Your code is the only > code with enough context to know whether what's been done so far > should be committed anyway despite the error or if the error should > cause the whole thing to be rolled back. I agree with you that a user code can best determine whether to roll back or commit. However, I think this is not reflected in the documentation for the models at all. http://docs.djangoproject.com/en/dev/ref/models/instances/?from=olddocs http://docs.djangoproject.com/en/dev/topics/db/models/#topics-db-models My understanding is that updates/insert/delete to database models are handled as auto-commit transactions (each model query is itself a transaction). However, in case of a failure, django gives me a bad state of the database. And my rest of the code fails if I do not explicitly handle the transaction commit/rollover. This seems really problematic for the programmer. If a single query fails, then what does commit mean. Shouldn't we do just rollover as commit has no meaning? -Sushant. > > Karen > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---