On Jan 14, 2014 3:15 PM, "Jeremy Evans" <[email protected]> wrote: > > On Monday, January 13, 2014 6:00:09 PM UTC-8, Andrew Hacking wrote: >> >> I've been looking through the associations code and it appears that #add_associated_object, #set_associated_object and #set_one_to_one_associated_object could be changed/overridden in a plugin to defer validation and saving via an after_validation_hook/after_save_hook like nested does if the model is new, and possibly also controlling this behaviour by an option. >> >> Specifically: >> 1) if the parent object is new for #add_associated_object then defer via after_validation_hook/after_save hook like nested attributes. >> 2) if the associated object is new for #set_associated_object and #set_one_to_one_associated_object then defer via before_validation_hook/before_save_hook. >> >> I can see some care will be needed for reciprocal relationships in (2) to avoid callback recursion but besides that problem do you see any other obvious pitfalls before I embark upon such an approach? > > > Well, delaying validation without also saving associated objects when the parent object is saved sounds wrong to me. By the time you implement that correctly, you've basically reimplemented nested attributes. > > In addition, you need to understand that the *_hook methods (e.g. after_save_hook) are not core methods, they are implemented by another plugin called instance_hooks. You'd basically need to reimplement that in core as well. As I mentioned earlier, you can't easily get nested_attributes features without reimplementing most of the plugin. >
I'm not suggesting implementing anything in core, I've already said I like core kept clean. I'm taking a pure plugin approach. Yes I've already had problems with instance_hooks in nested_attributes as they don't work if you do model.valid? followed by a model.save as they are one shot and get cleared as per the docs. Nested attributes probably should have a note about that since it leverages the behavior of instance_hooks. I've implemented my own instance hooks (called context_hooks) that don't automatically clear but instead require a manual clear and I am using this in both my deferred_associations plugin and also leveraging both context_hooks and the deferred_associations from my own nested_model plugin. The deferred associations plugin is very simple and just a few lines of code that defers validation and saving to after the parent validate/save much less than nested attributes. I'm only dealing with one_to_many currently but it does the job for now. >> >> Yeah I don't have any problems with nested_attributes (aside from deferring foreign key validation and creating new model instances based on sti key), my problem stems from capturing exceptions and accumulating model validation errors for manual association operations which may occur in model callbacks/hooks or web app controller code. > > > Assuming you are using nested_attributes, after you fix the foreign key validation issue, wouldn't that work in terms of accumulating model validation errors before saving? If not, could you provide some example code showing why it doesn't work for your use case? For most cases nested_attributes does the job but if I have other callbacks or controller code that manually calls say add_xxx to a model then I have to deal with catching exceptions and manually adding a model error, eg adding tags via a virtual string attribute that decides what needs to be done. I want the behavior in my models to allow wiring up models valid or not and just capture errors on the models and be able to build the object graph through both nested attributes and manually where needed and then validate/save it from the root of the graph and collect all errors on the root model. I am bounding the change scope to a DAG anchored at a root model with no cycles so this works well for many if not most web app use cases. Regards...Andrew -- You received this message because you are subscribed to the Google Groups "sequel-talk" 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 http://groups.google.com/group/sequel-talk. For more options, visit https://groups.google.com/groups/opt_out.
