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,

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?

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



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,

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

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 ;)