[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (BVAL-208) support groups translation when cascading operations (hosted on @Valid or not)

[Hardy Ferentschik (JIRA)]

    [ https://hibernate.onjira.com/browse/BVAL-208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=43531#comment-43531 ] 

Hardy Ferentschik edited comment on BVAL-208 at 4/3/12 8:09 AM:
----------------------------------------------------------------

I had two use cases in mind:

* define the group to validate in a method level annotation (parameter etc)
* let a user redefine the group to validate when cascaded (useful when aggregating object graphs)

Both use cases are well described by Arthur in [#comment-38181]

Note that @Valid left alone would still fulfill the default specification interpretation. But one could envision a "NAT" style transformation from one group to another when a @Valid barrier is crossed.

    {code}@Valid(before={Simple.class, Heavy.class}, after={Easy.class, Default.class}){code}

When Simple.class is validated in the mail object, Easy.class is validated on the cascaded object.
When Heavy.class is validated in the mail object, Default.class is validated on the cascaded object.

A couple of problems to resolve:

* what about circular dependencies involving different groups "for a while" (ie Default on the nested object validates back the root object).
* what about group sequences. Should direct groups be translated, or should inner groups be too? What about inconsistencies in this case (ie the translated group sequence violating group sequence rules).

Note that I had in mind to reuse @Valid but it might be better to have one (or even two) additional annotations for these notions (ie the cascading, the group translation, the method-levle group definition.

      was (Author: emmanuel):
    I had two use cases in mind:

* define the group to validate in a method level annotation (parameter etc)
* let a user redefine the group to validate when cascaded (useful when aggregating object graphs)

Both use cases are well described by Arthur in #comment-38181

Note that @Valid left alone would still fulfill the default specification interpretation. But one could envision a "NAT" style transformation from one group to another when a @Valid barrier is crossed.

    {code}@Valid(before={Simple.class, Heavy.class}, after={Easy.class, Default.class}){code}

When Simple.class is validated in the mail object, Easy.class is validated on the cascaded object.
When Heavy.class is validated in the mail object, Default.class is validated on the cascaded object.

A couple of problems to resolve:

* what about circular dependencies involving different groups "for a while" (ie Default on the nested object validates back the root object).
* what about group sequences. Should direct groups be translated, or should inner groups be too? What about inconsistencies in this case (ie the translated group sequence violating group sequence rules).

Note that I had in mind to reuse @Valid but it might be better to have one (or even two) additional annotations for these notions (ie the cascading, the group translation, the method-levle group definition.
  
> support groups translation when cascading operations (hosted on @Valid or not)
> ------------------------------------------------------------------------------
>
>                 Key: BVAL-208
>                 URL: https://hibernate.onjira.com/browse/BVAL-208
>             Project: Bean Validation
>          Issue Type: Improvement
>    Affects Versions: 1.0 final
>            Reporter: Marc Schipperheyn
>
> The @Valid annotation should implement the group attribute in order to make validation completely annotation driven. Currently, we need to manually call the validate method on the validator if we want to validate based on groups.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira