Yes, and then you're gonna have to think too about which order your callbacks get called when you do call save.... do the parent object callbacks get called first or do the child objects get called first? And what happens if one of the child before_save callbacks, or its validation, causes the object to be un-savable (in error state), do the rest of the related objects also not get saved?
It's an issue. I think an upgraded DSL (Domain Specific Language)-- which Active Record is wether it pretends it is not -- would be significantly more robust, allow for these kinds of design flaws to be sussed out and at least become transparent to the developer, and move away from over-reliance on the callback pattern generally. A sophisticated ORM could could use composition objects (like in DCI patterns) themselves representing business logic that you would attach callbacks to in certain context, giving them clear patterns of what gets called before what (as in the case of object chains), and what failure cases. It's one of the things people talk about when they talk about things they don't like about Active Record, you are absolutely right. It seems to me that your proposal could be done with an experimental "Add later" or "Destroy later" feature on the relations themselves, perhaps configuring inline in the spot where you make the call, or perhaps configured on the relationship level. This feature could then defer the changes on the relation until the primary object is saved. But, as I discussed above, when you think about the pandora's box of validation errors that this would open, you then understand why the existing Rails behavior eliminates these kind of flow problems by doing operations on relations immediately, as you correctly have identified. -Jason > On Jul 7, 2016, at 6:29 PM, Jeremy Mickelson <[email protected]> > wrote: > > I completely agree that it would a drastic change, very much not backwards > compatible. So something like this should not be taken lightly. I just > thought it was worth opening a dialogue because it seems to me that there is > a big self inconsistency with the way AR deals with in memory objects. > Attributes are modified only in memory until you call save, but associations > are saved to the database immediately (there is no way to do an in memory > change). That inconsistency cost our small company (3 developers) nearly a > hundred hours of head scratching to get around (which is very expensive for a > company of our size). > > I propose that as part of Rails 6, we change the way association > modifications are handle to have them only be in memory until save is called. ---- Jason Fleetwood-Boldt [email protected] http://www.jasonfleetwoodboldt.com/writing If you'd like to reply by encrypted email you can find my public key on jasonfleetwoodboldt.com <http://jasonfleetwoodboldt.com/> (more about setting GPG: https://gpgtools.org) -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/rubyonrails-core. For more options, visit https://groups.google.com/d/optout.
