On 4/10/2011, at 08:36 , Michael Koziarski wrote: >> Then, we could make the transaction around test runs be non-consistent?
Just bear in mind that the fixtures code does not use the #transaction method. > Consistent is possibly the wrong word to use there though, as it's the C in > ACID. I'm not sure I have a better suggestion though? > :track_instance_state, :rollback_instances? :remember_state, I think. Note though that all of these suggestions don't indicate whether or not after_commit and after_rollback will get called. If we go with one of them, then we will want to make sure that we remember objects that have after_commit or after_rollback events irrespective of this option - that seems like a reasonable idea to me though. But the question still stands about whether they should be fired by tests. If no-one cares, I guess we can just leave it implementation specifics. > fwiw it's not hard to construct cases where that per-instance rollback won't > work, so relying on it is pretty … brave. Oh, really? I thought that the justification given for the new code that went in 3.0 that remembers all objects was that it could fix those cases. If it didn't really fix anything, I'd argue for ripping it out as it is an overhead relative to 2.3. Could you give an example that's still not fixed? -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
