[hibernate-issues] [Hibernate-JIRA] Issue Comment Edited: (BVAL-256) Provide means for disabling constraints from super types

[ https://hibernate.onjira.com/browse/BVAL-256?page=com.atlassian.jira.plug... ] Matthew Hillier edited comment on BVAL-256 at 3/23/12 10:16 AM: ---------------------------------------------------------------- Just following on from the discussion on [http://lists.jboss.org/pipermail/beanvalidation-dev/2012-January/000137.html]. We would be very much in favour of some sort of @IngoreInheritedContraints annotation / processing. The use-case we are currently blocked on is one where we have a class-hierarchy that describes the fields required for an output file, based on country. As an example: We have a base bean file that describes all of the fields we are interested in capturing. By Default, we mark all fields as not required (@Size(min=0,max=0)), so that extending classes should only need to declare those fields that are required for the specific output file they implement. {code} public abstract class BaseFileRecord { ... @Size(min=0,max=0,message="Name is not required") public String getName() { return name; } @Size(min=0,max=0,message="Account Number is not required") public String getAccountNumber() { return accountNumber; } @Size(min=0,max=0,message="Account Code is not required") public String getAccountCode() { return accountCode; } } {code} For a file of "Type A", we implement a sub-class that defines the fields that are generally required for this type of file. Note that the Constraint violations now conflict with the ones that were inherited. {code} public class TypeAFileRecord extends BaseFileRecord { @NotNull @Size(min=1,max=50,message="Name should be no more than 50 characters") @Override public String getName() { return super.getName(); } @NotNull @Size(min=8,max=8) @Override public String getAccountNumber() { return super.getAccountNumber(); } } {code} For one country (in this case SG) the file of Type A describes that the "accountNumber" field should be 10 characters, and not 8. We would expect to implement this as follows. {code} public class TypeAFileRecordSG extends TypeAFileRecord { @NotNull @Size(min=10,max=10) @Override public String getAccountNumber() { return super.getAccountNumber(); } } {code} Note that in our implementation we are also using some custom annotations and the PropertyDescriptor / PropertyTypeDescriptor from the Spring framework to specify some additional requirements, such as whether a field is visible to the user or not. Using this, the PropertyTypeDescriptor instances all work as expected in that they only return the annotations on the lower-most implementation of each method. If BVAL were to support an @OverrideConstraint or @IgnoreInheritedConstraint annotation then this would allow our developers to ensure that their expectations for annotations are consistent. -I note that the XML validation configuration allows for this type of overriding to be done, which is all fair and good, but I would prefer that developers were able to configure all of these meta-data items in one place, so to reduce the risk of them missing vital configuration.- (Scratch that, XML configuration only applies overrides to the annotations placed on the sub-class, super-class annotations are still inherited - my bad!) was (Author: matthew.hillier): Just following on from the discussion on [http://lists.jboss.org/pipermail/beanvalidation-dev/2012-January/000137.html]. We would be very much in favour of some sort of @IngoreInheritedContraints annotation / processing. The use-case we are currently blocked on is one where we have a class-hierarchy that describes the fields required for an output file, based on country. As an example: We have a base bean file that describes all of the fields we are interested in capturing. By Default, we mark all fields as not required (@Size(min=0,max=0)), so that extending classes should only need to declare those fields that are required for the specific output file they implement. {code} public abstract class BaseFileRecord { ... @Size(min=0,max=0,message="Name is not required") public String getName() { return name; } @Size(min=0,max=0,message="Account Number is not required") public String getAccountNumber() { return accountNumber; } @Size(min=0,max=0,message="Account Code is not required") public String getAccountCode() { return accountCode; } } {code} For a file of "Type A", we implement a sub-class that defines the fields that are generally required for this type of file. Note that the Constraint violations now conflict with the ones that were inherited. {code} public class TypeAFileRecord extends BaseFileRecord { @NotNull @Size(min=1,max=50,message="Name should be no more than 50 characters") @Override public String getName() { return super.getName(); } @NotNull @Size(min=8,max=8) @Override public String getAccountNumber() { return super.getAccountNumber(); } } {code} For one country (in this case SG) the file of Type A describes that the "accountNumber" field should be 10 characters, and not 8. We would expect to implement this as follows. {code} public class TypeAFileRecordSG extends TypeAFileRecord { @NotNull @Size(min=10,max=10) @Override public String getAccountNumber() { return super.getAccountNumber(); } } {code} Note that in our implementation we are also using some custom annotations and the PropertyDescriptor / PropertyTypeDescriptor from the Spring framework to specify some additional requirements, such as whether a field is visible to the user or not. Using this, the PropertyTypeDescriptor instances all work as expected in that they only return the annotations on the lower-most implementation of each method. If BVAL were to support an @OverrideConstraint or @IgnoreInheritedConstraint annotation then this would allow our developers to ensure that their expectations for annotations are consistent. I note that the XML validation configuration allows for this type of overriding to be done, which is all fair and good, but I would prefer that developers were able to configure all of these meta-data items in one place, so to reduce the risk of them missing vital configuration. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira