How very interesting. The callback and validation logic that you bring up sounds like it could get complicated fast.
>From the perspective of my use case, I would expect none of the records to save. I have a CommunicationSetting that is treated as one big object from the perspective of the app, but it’s storage is split across multiple AR Models and tables. So what I am doing is modifying a communication setting and its sub records, then calling .save! on the communication setting. If any of the validations failed I would want nothing to save and none of the after save callbacks to fire. I can see how this could get complicated, but it seems like it could be manageable by looking at which object originally received the save call and treating the whole thing like one atomic operation. In fact isn’t this the way it currently works for modifications (as opposed to deletes), as long as you have autosave: true enabled on the relation. If I have a parent object and I modify both it and some of it’s child records, what happens if some of the validations fail? This is how I currently have my CommunicationSetting class set up and it works great, for everything except deletions. I would be totally cool with an “add/destroy later” feature that I could enable on the relation because that would allow me to configure this meta record to work the way I want. If we did it that way it wouldn’t even be backward incompatible and wouldn’t have to wait for Rails 6. Jeremy On Thu, Jul 7, 2016 at 4:11 PM, Jason Fleetwood-Boldt <[email protected]> wrote: > 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 (more about setting GPG: https://gpgtools.org) > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Ruby on Rails: Core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/rubyonrails-core/83e0K_eAYjU/unsubscribe > . > To unsubscribe from this group and all its topics, 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. > -- 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.
