Ah, sorry, I should have read it closer. I didn't realize that errors in after_save/after_create would roll back the save.
On Mar 7, 4:40 pm, Eloy Duran <[email protected]> wrote: > They are inside the transaction because of the reason mentioned in the > article you linked to: > > > I noticed a troubling thing about using after_save to expire > caches, after_save is still within the transaction that save is > automatically wrapped in. I assume this is to protect against an error > during the after_save call, so you can roll back the database to it's > previous state. > > So maybe a patch to add the after_commit API, as used in the article, > would be a good idea. > > Eloy > > On 7 mrt 2009, at 15:34, Alex MacCaw wrote: > > > > > I've got a message queue running, and record ids get added to it in an > > after_create callback. > > > However, the message queue is so fast that it can't find the records. > > This is because the record hasn't actually been saved back to the > > database yet - after_create is called in the transaction. > > > There's more information on this problem here: > >http://elimiller.blogspot.com/2007/06/proper-cache-expiry-with-afterc... > > > I'm wondering, is there a reason why after_save and after_create are > > called inside the transaction? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
