On Jan 14, 2014 5:04 AM, "Jeremy Evans" <[email protected]> wrote: > > On Monday, January 13, 2014 6:52:00 AM UTC-8, Andrew Hacking wrote: >> >> >> I would like to be able to quash exceptions and just examine model errors. I can almost do this when using the nested attributes plugin due to the way it avoids validating on save and instead uses an after_validation_hook/after_save_hook (but this has problems for (eg automatic) validations that check foreign key presence on new parent records). > > > Well, I don't think those problems are solveable. If you have a validation the depends on the foreign key being set, and you can't know the foreign key value until after the parent object is saved, you can't validate the associated objects without saving the parent object first. >
Two options I am looking at currently in my custom nested attributes and auto validations plugins are to defer foreign key validation checking until after the parent save or to just validate and save the nested record in the after_save_hook and not use the after_validate_hook at all. Since I use transactions I can rollback changes for a request when an error is detected but it would have higher overhead. Related to validating associated records I also want to have checks for cardinality and currently this only seems feasible after save of an object graph if you care about things being valid in the face of concurrency. I may not even use sequel for this aspect but I desire where possible to return a set of validation errors specific to the problem attributes as opposed to a something went wrong exception. >> >> I share the backward compatibility concern but I would prefer the behaviour of the core option to follow the principle of least surprise. I regard the current behaviour as somewhat surprising. This could be fixed with documentation and a plugin similar to some of what nested attributes does, but it does feel a bit like adding a patch plugin to get correct intent. > > > I think the backwards compatibility issue is significant enough that changing existing behavior cannot be made without a major version bump (e.g. until Sequel 5), if it even can be made at all. Changing this behavior breaks code in bad ways, equivalent to silently swallowing exceptions. > Sure, I was anticipating that so best to just clarify the documentation describing the limitations of raise_on_failure et al. >> >> Perhaps the middle ground is to do it in core using a hook like nested_attributes does so that model errors can be accumulated and examined on an error, and allowing a special raise_on_failure/raise_on_save_failure value of :none/:never as well as preserving the current falsey/truthy value behaviour. > > > I'm not sure how this could be done without reimplementing much of nested_attributes in core (which I don't want to do), but I'll consider this approach it if could be done in a simple way. > I'm happy with whatever you judge as appropriate. I like keeping core as clean as possible so its easier to understand and not bloated with unwanted concerns. >> >> Ultimately I don't mind how we get the behaviour, I'd just like to avoid raising exceptions and examine model.errors as this works nicely when implementing JSON API's or handling complex form errors in web server code. > > > FWIW, I'm not sure why you can't use nested_attributes. The problem you have with nested attributes is inherent, it's not specific to the implementation of nested_attributes. nested_attributes is designed specifically for the use case of handling associated objects and combining validation errors. > I do use a modified nested attributes plugin as I also want to deal with sti type handling. However I also need to manually manipulate relationships based on various rules. Hence wanting the association add and assignment and remove methods to something like what nested does. I am working through this right now to get a project delivered and investigating various ways forward so its likely I'll deal with it in plugin(s). I'll be happy to contribute my solution for consideration for integration into sequel. > As an aside, I realize using exceptions for flow control is bad, but I think the returning false from save (and similar methods) is worse. The former makes it just slightly more difficult to deal with bad records. The latter makes it easy to silently ignore errors. For that reason, I discourage setting of raise_on_save_failure = true. > I never want errors silently swallowed either hence in my case wrapping all requests in a transaction, checking for model errors and rescuing exceptions so as to be able to return a useful Api response. But I do want errors to do with user input validation to be useful to clients and dealt with consistently in a nice errors hash and associated to the problem attribute(s). Raising exceptions when adding associated models makes it harder than it should be to accumulate model errors, and it also potentially short circuits validation (you don't get all possible validation errors) hence my need to develop alternative solutions. 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.
