All good stuff, thanks. I have some follow-ups. -Are you telling me that I cannot roll back transactions unless I rip out the middleware? There's no accessible command to the middleware with TG2 as it ships?
-How can I lock a table? I thought that was done by TG as well - that each call to a controller made the database safe to access. -I actually do want to roll back *all* the previous transactions made in that sessions. It was an all-or-nothing scenario. If there's a single duplicate in that database, then I want to remove all of the new entries added during this call. I would expect rollback() wouldn't remove items already in the database from a previous call to the controller (which ends with a commit() as I understand it, perhaps in repoze.tm2 as you point out?) If this is documented from a TG2 perspective somewhere, I would love to know where - I'm not afraid of reading, but figuring out how SQL Alchemy is integrated with TG2 has been difficult. Thanks for the help. El Tea On Jul 30, 2:32 am, "Diez B. Roggisch" <[email protected]> wrote: > El Tea schrieb: > > > > > Let me preface this by saying I may still not having a sufficient > > grasp of SQL Alchemy. > > > I am adding a set of entries to the database, one at a time. Before > > adding each entry I check to ensure a similar entry is not in the > > database. If there is, I consider the entire set invalid and attempt > > to do a rollback. So, in pseudocode: > > > Loop through my input data: > > Query DB to check for duplicate > > if not duplicate: > > DBSession.add(entry) > > if duplicate: > > DBSession.rollback() > > return #Returns to the controller method, which then returns > > result > > data for rendering. > > > I keep getting the following error: > > > InvalidRequestError: The transaction is closed > > Transactions in TG2 are managed through the repoze.tm2 middleware, *not* > by you. Unless of course you rip that out, as we did. But that's another > story. > > However, in any case the above code is faulty. You don't rollback a > transaction when you'd have a duplicate entry, because then you'd > rollback *all* the previously successfull creations. That's the way > transactions work. > > Instead, you do nothing. > > And if you want to make 100% sure you don't run into a race-condition, > you first lock the table you are working with, because otherwise it can > happen that between checking for a row, and creating it, it is created > by another request. > > Diez --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/turbogears?hl=en -~----------~----~----~----~------~----~------~--~---
