> (1) is already covered (by just raising an error). What about the > following scenario though: > > 1. do database operations X, Y > 2. figure out that operation Z is impossible > 3. rollback X and Y, and do something else. > > As long as I have this code in an application, everything is fine and > dandy. What if I need to do it in a library method, which is not > guaranteed to be the top-most transaction()? > > > So, (1) covers 90% of cases, but those are already covered by other > means. (3), on the other hand, covers the remaining 10%.
You can cover the remaining case by manually calling rollback! on the model's connection. Case 3 seems completely broken because it means code inside a transaction block is no longer guaranteed to be atomic. transaction do @model.operation_one txn.rollback! @model.operation_two end instead of one and two being all ACID like, you get operation two committed to the db with operation one nowhere to be seen. That seems like a much more dangerous situation than having op two never called. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
