-->
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: Looks promising, but I have some doubts
PostPosted: Mon May 05, 2008 1:50 pm 
Regular
Regular

Joined: Fri Jul 29, 2005 9:46 am
Posts: 101
Hi!
I posted this same comments at the In Relation To... but then I realized this was a better place for them (so, I apologize for posting them twice) :

What if I need to run a JPAQL query to find out if my object is valid (for example look in a zip-code table mapped by one of my POJO classes) how can I reach the EntityManager from inside the Validator? (Please don't just tell me "that is a bad practice", I think this validation framework should be able to set a standard way to validate persistent objects, and for that you need to do queries, perhaps not inside you entity pojos, but you need to do them somewhere, and it is better if the place to do that is standarized)

Not all validations need to be checked for the same persistences operation, some should be checked for INSERT, some for UPDATE and some others for DELETE: How do I specify that want to validate, by running a query, before delete? (For example, you can not delete a Customer that still owes some Payments because of the Orders he made in your internet shop)

How can I generate detailed error messages for Class-level constraints, currently it seems I can only say it is valid or it not valid but it doesn't allow to expose contextual information explaining why it is not valid or if it was found to be invalid on INSERT, UPDATE or DELETE?. (It seems I can extract some contextual information from the properties of the annotations, but, what if I want to get some information from the database and show it my error message?) Something like: You cannot buy this {bike} because it costs {1000} and your available credit is {950} (The name of the thing I am trying to buy and its cost and in the "Merchandise" entity, but my available limit need to be re-calculated each time by querying the "Account" entity and my previous still unpaid "Orders")

Thanks,
Regards,


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 06, 2008 3:41 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
There are already two posts talking about the features you're talking about:

- Being able to specify several error messages in bean-level validation, and associate properties to those errors: http://forum.hibernate.org/viewtopic.ph ... 80#2383880
- Being able to specify conditional and event-based validation, in order to run validation on INSERT/UPDATE/DELETE: http://forum.hibernate.org/viewtopic.ph ... 95#2381895 (although in this case I failed to really make a case why I would need to validate on something else than CHANGE events, but I guess your example makes sense, so I can resurrect the first proposal which had more events like INSERT/UPDATE/DELETE).

What do you think of those?

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 06, 2008 10:31 pm 
Regular
Regular

Joined: Fri Jul 29, 2005 9:46 am
Posts: 101
FroMage wrote:
There are already two posts talking about the features you're talking about:

- Being able to specify several error messages in bean-level validation, and associate properties to those errors: http://forum.hibernate.org/viewtopic.ph ... 80#2383880


I like the idea proposed in that thread. Maybe I'll just add that it could better if the Pojo itself becomes the ValidationListener (with an annotated Map property to store errors, something like IDataErrorInfo but based on annotations instead of an interface

FroMage wrote:
- Being able to specify conditional and event-based validation, in order to run validation on INSERT/UPDATE/DELETE: http://forum.hibernate.org/viewtopic.ph ... 95#2381895 (although in this case I failed to really make a case why I would need to validate on something else than CHANGE events, but I guess your example makes sense, so I can resurrect the first proposal which had more events like INSERT/UPDATE/DELETE).

What do you think of those?


I think the support for knowing if the validation should be triggerd at INSERT/UPDATE or DELETE is a must... but I am not sure about the rest (the conditional and event-based validation) I think that kind of logic may be better expressed with common control structures (like if...else if... else inside a class level constraint).

My main concern with this new validation API are those validations that require a database query to be done (like in the The Calendar Application Problem, I just think that is the kind of validation that should be the primary target of this specification (I am somehow feel that is precisely the kind of validation that may not be supported at the end)

Regards,


Top
 Profile  
 
 Post subject: Re: Looks promising, but I have some doubts
PostPosted: Wed May 07, 2008 12:31 pm 
Beginner
Beginner

Joined: Fri Jan 14, 2005 7:47 am
Posts: 37
Location: Spain
luxspes wrote:
Hi!
Not all validations need to be checked for the same persistences operation, some should be checked for INSERT, some for UPDATE and some others for DELETE: How do I specify that want to validate, by running a query, before delete? (For example, you can not delete a Customer that still owes some Payments because of the Orders he made in your internet shop)

What do you think about this solution :
http://forum.hibernate.org/viewtopic.php?t=985993
?


Top
 Profile  
 
 Post subject:
PostPosted: Fri May 09, 2008 5:20 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
The event-based validation is actually what you are referring to with INSERT/UPDATE/DELETE. Those are _events_ in the sense that they are phases that happen, during which we want to trigger validation.

The conditional validation is validation rules that should be enabled based on conditions. The fact that they are writable as bean-level validation is irrelevant because it is a matter of style and personal preference: some people like to have all the validation at the same place, using annotations on properties, rather than having some annotated properties, and a non-reusable bean-level validator class sitting somewhere out of sight of refactoring.

The event-based validation is treated in my proposal as a type of conditional validation in the sense that the validators will be run under the condition that the specified event (INSERT/UPDATE...) is occurring.

I like your proposal of JPA triggering automatic validation groups, and if it comes to that I suppose I can use it, as long as conditional validation is supported otherwise ;)

_________________
--
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.  [ 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:
cron
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.