Hello, Frederick: Thanks for your response, that was very helpful both in validating my approach, and suggesting other ways to accomplish this.
I'm still surprised this issue hasn't come up for others ... does anyone else have input on how this should/shouldn't be performed, or how they solved this issue? (For those just tuning in, I need all the updated_on/created_on timestamps, in a series of AR object created/updated within a transaction, to match exactly) Thanks again, Ruby On Thursday, May 21, 2015 at 5:20:59 AM UTC-4, Frederick Cheung wrote: > > > > On Thursday, May 21, 2015 at 6:58:35 AM UTC+1, Ruby Railhead wrote: >> >> >> Idea 3: Subclass ActiveRecord::Base (to say ActiveRecordLocal) and mix in >> the modules mentioned above into this class. >> Thoughts: This makes is clearer that when you're using ActiveRecordLocal, >> you're not getting the stock ActiveRecord::Base behavior. Otherwise this >> solution is identical to Idea 2. >> >> > Of the ideas you outline, I would either do this or: > > - use SomeModel.record_timestamps = false to stop active record setting > timestamps > - use before_save / before_create callbacks (or override save) to set > your own timestamps > - continue overriding transaction in order to get your start of > transaction timestamp. > > The reason for this slightly different strategy is that it means you're > only overriding public methods, so their api will remain stable (or at > least go through the usual deprecation cycle) across versions of active > record. > > Fred > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/4674c558-dbba-4b48-9f27-ed9f1ac00406%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
