-->
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.  [ 43 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject:
PostPosted: Wed Jan 21, 2009 5:53 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
Not sure I follow you. If you want to redefine the message of a class level constraint, use addError(String)
If you want to apply it on a property of the class, use addError(String, String).


OK that was me not reading properly then ;)

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:06 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
Page 68 wouldn't it make it easier to use if BeanDescriptor had a getTypeConstraints() or getBeanConstraints() or getClassConstraints() (however it is named) which returns the class-level constraints? It seems to be missing and since there is a hasConstraints() method there, it seems fitting to include them there.

I suspect they would be included from the ElementDescriptor.getConstraintDescriptors() but still, why make this harder than for property constraints?


ElementDescriptor.getConstraintDescriptor() does return the element level constraints. This is true for BeanDescriptor, PropertyDescriptor, Parameterdescriptor etc. not sure why you think it's different between proeprty and bean.

BTW I am planning to move hasConstraints() up to ElementDescriptor


Aha, so the BeanDescriptor.getConstraintDescriptors(); only lists class-level constraints, in order to get to the property constraints we have to use BeanDescriptor.getConstraintsForProperty(...).getConstraintDescriptors().

Now I get it, it totally makes sense.

I was misled by ElementDescriptor.getConstraintDescriptors()'s javadoc which says "Returns all the constraint descriptors for this element." In my mind, the list of constraints on a bean included both the class-level and property-level constraints. This is just me making invalid assumptions.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:10 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
I think that's the job of the integrating framework, JSF for example.
We thought about an integration possibility where org.hibernate.constraints.Email.js would be picked up when JSF needs a JS function implementing the validation.
Unfortunately this will not be standardized in this JSF release.

I like composing constraints as a way to expose the encessary metadata and let each framework define how to express out of java constraints.


I understand not everything can be standardised, but I wonder if frameworks do(will?) the integration themselves. I don't think Seam does it for example (maybe I'm wrong).

The important part is being able to define your own JavaScript (for example, or SQL) for your own custom constraints, and not just having the framework treat _known_ constraints and ignore your custom ones.

Is there anything in Hibernate that let us define custom SQL constraint mappings for custom HV constraints for instance?

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:14 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
We use @AssertFalse on methods a lot to make higher-level checks for a given property. Yet when we return false from the method, we can set the message correctly, but the associated property is gotten from the name of the checking method when really this method was just checking another property:

Code:
class Foo {

String bar;

@AssertFalse
public isBarValid(){
  return bar != null && bar.equals("yeah");
}
}


This would report that the invalid property is "barValid" when really for us it is "bar". Again I know we can set the message correctly, but could there be a way to set the applicable property too?


well I would rather have a @ValidBar constraint set at the class level with the logic you describe in an actual Constraint implementation. from there you can define the property the constraint violation is applied to ConstraintContext.addError(String, String)


You're probably right, it's a matter of style though, I prefer splitting up validation into small focused functions close to the definition of what they validate, as opposed to an external validator class away from the validated bean implementation.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:15 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
Is there a way to perform all validation without stopping at the first constraint violation?

We use Hibernate Validation to check REST provided JAXB entities, and we would like to report not only the first error, but all errors. Is there a way to do that with Validator other than iterating manually over all validators using the introspection API?


Yes that that's the default :) Actually today there is no way to stop at the first violation :)


OK, great move ;)

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:17 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
Can we get unicity constraints mapped to BV errors too? Please?


Unfortunately looks like this one is not going to make it :( Maybe we can do that in Hibernate


That'd be a great start :) And definitely good enough for us as we use Hibernate.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:21 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
Page 88:

Quote:
Java Persistence delegates the validation of entities to BV on the following entity events:
- pre persist (an entity must be valid to be inserted in the DB)
- pre update (an entity change must be valid before being propagated to the database)
- pre remove (eg. a Customer still owning some Payments cannot be removed)
- question has been asked about post load. What would be the value add?


The value added would be for application upgrades when the DB data is from a previous application with a compatible schema but different BV constraints, or when developing using SQL imported test data that might become invalid when new constraints are applied. We've had these cases before and an error early on (when loading them) would be nice.


But then what would you do with them? Validating on change is one thing but validating on load is a whole different story.


What you'd do is have the application throw exceptions before it's a bit late to notice it. Right now it is possible to have invalid data in the DB, load it in JPA, then when saving (the exact same data) a validation exception is thrown.

I think once you have put validation constraints which are applied when saving to the DB, you mean that everything in the DB has to be valid. If you load something which is invalid you then might want to know asap.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:22 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
On Page 91 about the integration with JSF2 I don't see anything that makes me think that the beans holding the edited properties would be validated.

I feel strongly that validating single properties one at a time is not enough in most cases, as it bypasses class-level validation and higher-level property validation (such as @AssertXXX methods). This forces us to not be DRY and implement JSF validators.

The problems stems from JSF checking and applying property values one at a time when BV needs all properties to have been set before it can call class-level validation (and also validate the other non-edited properties).

Isn't there any way to have the ModelValidator be a bit smarter and if all edited properties have been validated, then validate their owner bean instances according to regular BV rules? If that then fails, you can revert the edited properties and return a failure to JSF.

I feel strongly that this is a key issue.


That's correct. While we all agreed that this was an important concern, we could not agree on a natural way to validate whole beans rather than simple properties and decided to keep it for later. I hope natual JSF / Bean Validation provider innovation will fill this gap and that we will be able to standardize that in the next rev.


Fair enough, I hope that too ;)

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Jan 21, 2009 6:25 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
FroMage wrote:
Let's not forget: un grand bravo for this specification, it looks very serious and well done.


Thanks. And thank you for all the feedback. We disagreed at time but the spec got better from all these exchanges.


I think you're wrong: I never disagree ;) (poor humour)

Really, I appreciate it a lot to see such an open JSR where we can see it grow up and give feedback, once again many thanks for the great work, and for the time you put in answering user feedback.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 22, 2009 10:35 am 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
FroMage wrote:
emmanuel wrote:
I like the idea. It would make sense to move it completly out of the class?

Code:
@GroupSequenceProvider(FooSequenceProvider.class)
public class Foo {
}


To be honest it might not be part of the spec but it would totally make sense to add it in the RI.
http://opensource.atlassian.com/project ... se/BVAL-85


OK, I can totally live with it being in the RI since that's probably what I'll be using ;)

As for putting it in another class I like the possibility of being able to do it, but in several cases I like my validation to be self-contained withing the validated class, so if that could _also_ be possible it'd be great. I don't see any reason to limit the location of this provider to be only external to the validated bean, but maybe you thought of one reason I've overlooked?


Because:
- all other 303 constraints validation logic are out of the class
- you can use a static inner class to keep everything inside the main class if you want to

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Thu Jan 22, 2009 10:42 am 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
FroMage wrote:
emmanuel wrote:
I think that's the job of the integrating framework, JSF for example.
We thought about an integration possibility where org.hibernate.constraints.Email.js would be picked up when JSF needs a JS function implementing the validation.
Unfortunately this will not be standardized in this JSF release.

I like composing constraints as a way to expose the encessary metadata and let each framework define how to express out of java constraints.


I understand not everything can be standardised, but I wonder if frameworks do(will?) the integration themselves. I don't think Seam does it for example (maybe I'm wrong).


Note today but it's definitely in our plans :)

[/quote]
The important part is being able to define your own JavaScript (for example, or SQL) for your own custom constraints, and not just having the framework treat _known_ constraints and ignore your custom ones.

Is there anything in Hibernate that let us define custom SQL constraint mappings for custom HV constraints for instance?[/quote]

I need to think about something, the previous approach used by Hibernate Validator was too invasive for the spec.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 26, 2009 6:01 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:

Because:
- all other 303 constraints validation logic are out of the class
- you can use a static inner class to keep everything inside the main class if you want to


OK, those are valid points, but I don't think I can return a state-dependent list of validation groups from a static inner class. In that case the bean instance has to be passed as parameter to the function. (I also have to admit I've forgotten the meaning of "private" modifiers of an outer class for inner static classes)

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Mon Jan 26, 2009 6:03 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
emmanuel wrote:
Note today but it's definitely in our plans :)


Great!

emmanuel wrote:
I need to think about something, the previous approach used by Hibernate Validator was too invasive for the spec.


I didn't even know it was possible to define custom SQL validation keywords from custom (as in user-defined) validation constraints in HV.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 43 posts ]  Go to page Previous  1, 2, 3

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.