-->
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.  [ 6 posts ] 
Author Message
 Post subject: Question about validation and persistence constraints
PostPosted: Tue Apr 01, 2008 11:25 am 
Regular
Regular

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

Is there an effort to specify the integration between JSR303 validation
constraints and EJB3 persistence constraints.
For instance there are two ways to map the "NOT NULL" persistence
constraints:
@NotNull (JSR303, or at least Hibernate Validator)
@Column(nullable = false) (EJB3 persistence)

The EJB3 constraints do not lead to the same validation exception
(InvalidStateException in Hibernate Validator, unknown for EJB3
constraints) which is troublesome.
What is even more troublesome for us is the unicity constraints (on a
single column or multiple columns). Those cannot be expressed (at least
trivially) using Hibernate Validation (hence probably JSR303 too), which
forces us to have two sources of validation.

Is there any effort in this specification to address those issues?

I see that the EJB3.1 is under construction, maybe I should post that question there too...

Thanks.

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Wed Apr 02, 2008 6:08 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
In short, yes. The two expert groups will discuss how to integrate nicely JPA 2 and Bean Validation. same for JSF and Web Beans.
The idea is not to have to declare @Column(nullable) when @NotNull is present.

Unicity constraints is an entirely different business. Unless you acquire a table lock, it is basically not possible to check for unicity through a SQL query and hence to implement a correct validation implementation. Nevertheless, The spec comes with a pluggable constraintFactory that can be implemented by the application framework of your choice (Seam, Web Beans, Spring, Guice) and hence inject resources.

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 1:31 pm 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
But JPA _has_ unicity constraints, which ends up mapped as DB unicity constraints, or am I missing something?

The problem I have with those -- and with @Column(nullable = false) -- is that they are not the same framework as JSR303 and thus we cannot specify localised error messages or even _know_ what sort of validation exception will be thrown by it.

Maybe this is something to ask to the JPA people (is it still within EJB3.1 JSR?)...

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Thu Apr 03, 2008 2:33 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
I am part of the "JPA people" :) The spec is driven under the Java Persistence 2.0, not EJB 3.1

The unicity (and the not null for that matter) are applied on the DB schema but not validated at runtime (only by the DB really). Do you mean you want a @Unique constraint that does nothing in isValid but provide some infos to JPA for the DB schema generation?

_________________
Emmanuel


Top
 Profile  
 
 Post subject:
PostPosted: Sat Apr 05, 2008 5:34 am 
Regular
Regular

Joined: Tue Apr 01, 2008 11:10 am
Posts: 69
I mean that to a developer, it should not make any difference whether @Column(nullable = false) or @NotNull is used, and therefore both should be equivalent in effect. That is, both should (if supported by the underlying DB) set a NOT NULL constraint, and if validation fails (whether at the java validation level or at the DB level) they should raise the same exception (InvalidStateException presumably), which should suppport localised messages in both cases.

And for the same reasons, the @Unique constraints, which I understand why they are in JPA and done purely as DB-layer checks, should also generate the same exception (wrapped by the jsr303 validaiton layer or not) and support localised messages. For consistency's sake.

Most developers will not really want to care whether one validation annotation comes from JPA or JSR303. If presented with annotations from both APIs that sound roughly the same but actually have slightly different semantics and different exception behaviour, it will be confusing. I'm against confusion :)

So there is some level of interaction/integration that I expect from JPA and JSR303, even though I understand JSR303 has a broader scope than JPA. Overlapping functionality with different semantics is confusing. Hell, I think I understand the differences but still I get confused. Maybe it's just me though, I'm certainly not ruling it out ;)

_________________
--
Stéphane Épardaud


Top
 Profile  
 
 Post subject:
PostPosted: Mon Apr 07, 2008 4:44 pm 
Hibernate Team
Hibernate Team

Joined: Sun Sep 14, 2003 3:54 am
Posts: 7256
Location: Paris, France
You are correct in theory. Not sure how feasible it is. The point is noted.

_________________
Emmanuel


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 6 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.