-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: Property level validation dependent on another property
PostPosted: Wed Mar 22, 2006 2:38 pm 
Beginner
Beginner

Joined: Wed Feb 25, 2004 6:23 pm
Posts: 39
Annotations version: 3.1beta8

I'm currently working on eliminating duplicate validation information in our app. We are thinking of moving exclusively to Hibernate annotations for validation, which means the validation annotations would be used at every layer: UI (Swing based) to DB. However, some of our objects have properties whose validation is dependent on other properties (and even other objects). For example, I'd like to write a validation that ensures a Set property is a subset of another Set. So, the annotation might look something like this:
Code:
  @SetsetOf(superset='availableReportColumns')
  public Set<String> getSelectedReportColumns()
  ...
  public Set<String> getAvailableReportColumns()

However, after digging around the validation code, I can see that this is very difficult since Hibernate does not pass any "context" to the validator class for a property. In other words, my custom validator won't know the actual bean being validated and so will not have access to any other bean properties. This forces me to write a bean level validator, which is not as convenient:
Code:
  @SetsetOf(subset='selectedReportColumns', superset='availableReportColumns')
  public class MyBean {
    public Set<String> getSelectedReportColumns()
    ...
    public Set<String> getAvailableReportColumns()
    ...
  }


My question is: am I approaching this the wrong way? Or would it actually make sense to create a JIRA request for some kind of "context" to be passed into the property level validator? The "context", in this case, would allow my property level validator access to other properties on which it depends.

Thanks,
Anodos


Top
 Profile  
 
 Post subject:
PostPosted: Thu Mar 23, 2006 1:18 pm 
Beginner
Beginner

Joined: Wed Feb 25, 2004 6:23 pm
Posts: 39
If I don't get a response here, I'll assume I should just open up a JIRA issue.


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 24, 2006 4:48 am 
Newbie

Joined: Tue Jan 03, 2006 7:30 am
Posts: 18
Location: Budapest, Hungary
Suppose you annotated the selected column list to be the subset of the available column list. Now, change the available list. The change will be valid (there's no validator on either the available list or the whole bean), so it will be committed -- even if you just removed a selected column. Not good. How can it be helped?
  • You could annotate the reverse constraint as well, i.e. say that the available list is the superset of the selected list, but this is error-prone - you have to keep the two validators in sync, remember to use them in pairs etc.
  • The validation engine could check if the change affects a validator on some other property, which is inefficient and probably quite impossible.
  • Auto-generating the reverse annotation is a bit more efficient, but also unreasonably hard. It can have surprising effects for the user as well. (validator order and inheritance spring to mind)

So I'd say bean level validators are not only the only currently possible way, but probably the only right way as well. What are your problems with that, why isn't it convenient?


Top
 Profile  
 
 Post subject:
PostPosted: Fri Mar 24, 2006 1:49 pm 
Beginner
Beginner

Joined: Wed Feb 25, 2004 6:23 pm
Posts: 39
First off, I'm not sure if Hibernate validates single properties in isolation? Doesn't it revalidate the entire bean every time? This means if you changed the superset and the subset property was no longer a subset, then the subset property would not pass validation since Hibernate would recheck it before doing anything with the object.
However, if my assumption is false and Hibernate does (or can) validate properties in isolation, then why not introduce the idea of dependencies into Hibernate's Validator interface? Hibernate's Validator interface currently defines two methods: isValid and initialize. Why not modify 'initialize' to look something like this:
Code:
   public ValidationDependency[] initialize(A parameters);

ValidationDependency could be a simple class (for now):
Code:
public class ValidationDependency implements Serializable {
  private final String propertyDependency;

  public ValidationDependency(final String propertyDependency) {
    this.propertyDependency = propertyDependency;
  }

  public String getPropertyDependency() {
    return this.propertyDependency;
  }
}


In my initialize method for the @SubsetOf validator, I could do this:
Code:
  public ValidationDependency[] initialize(SubsetOf parameters) {
    ...
    return new ValidationDependency[] { new ValidationDependency(parameters.superset()) };
  }


Hibernate could then ensure that whenever a property with dependencies is validated, all dependent properties get validated as well.


Top
 Profile  
 
 Post subject:
PostPosted: Sat Mar 25, 2006 9:45 am 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
I'm not against passing some kind of context to the isValid method (like the object instance owner) if there are some usecases for it, but in your case I think it makes a lot of sense to use a bean level validator.

_________________
Emmanuel


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.