File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Object Relational Mapping and the fly likes JPA and Composite index Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » Object Relational Mapping
Bookmark "JPA and Composite index" Watch "JPA and Composite index" New topic
Author

JPA and Composite index

Luan Cestari
Ranch Hand

Joined: Feb 07, 2010
Posts: 125

Hi guys.

I got a very different problem in my work. First of all I will give some details of the DB. There is a table with an index with two columns, one is a integer and another one is a FK to other table. This one has an index for the PK and another integer columns. What this really means is that I can have a unique pair of integers from those two tables. Well, those indexes are unique, so I have a constraint. Now, looking on java code, I have mapped the entities but I don't know what annotations I can use to validate this constraint.

To solve it, but I don’t really think it is the best way, I put uniqueConstraints attribute in @Table on class of the first table that I talked about. And then, on the getter of Integer field, I created a annotation using a ValidatorClass annotation with a class that check in DB if the constraint will not be violated, in case of data insertion. Is it a good way? I did it due I have to display a message on a web page in case of try to violate. I thought that would be good if I leave this kind of logic in the entity, but looks like that every time that I call the get, the validation is called, and sometimes would be unnecessary.

So, what the ways to validate constraints of composite index with JPA? What would be the best practice for cases like this?

Thanks.

Best Regards,
Luan Cestari


Please, visit me for some cool tech post at www.ourdailycodes.com
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
Hi Luan,

Let me make a few points to help you understand what JPA does and does not do.

First off, JPA does not do validation in the sense of validating the database. There is a validation spec that does validation of the entity model, but a) it is a separate spec that happens to integrate with JPA, and b) it does not do any validation of the data model, or even integrate with the schema that JPA is mapping to.

Secondly, JPA supports a number of annotations and elements that provide vendors with the ability to perform schema generation. The JPA spec itself does not define schema generation, although most vendors support it, but the annotations and elements, such as @UniqueConstraint, are used exclusively for DDL generation when it is supported. They are not defined for use in validating an existing schema or for anything other than if a vendor supports DDL gen during an early stage of deployment. Some vendors may have chosen to add their own features and interpretations of what a given JPA annotation might mean for validation but this is definitely not according to spec, not portable, and not recommended.

So, given that your uniqueConstraints in @Table will not portably cause any validation at all, and that your hand-rolled validator accesses the database every time anyone touches the attribute, I would not recommend that approach. (I don't think I even want to know how you access the DB given that there is no portable way to access a native JDBC Connection). Depending upon how often it really happens in practice, a better approach might be to just go ahead and optimistically do a flush and handle/look at any resulting exception to see if the db constraint was violated, then report back to the user.

-Mike
Pro JPA 2: Mastering the Java Persistence API
Luan Cestari
Ranch Hand

Joined: Feb 07, 2010
Posts: 125

Mike Keith wrote:Hi Luan,

Let me make a few points to help you understand what JPA does and does not do.

First off, JPA does not do validation in the sense of validating the database. There is a validation spec that does validation of the entity model, but a) it is a separate spec that happens to integrate with JPA, and b) it does not do any validation of the data model, or even integrate with the schema that JPA is mapping to.

Secondly, JPA supports a number of annotations and elements that provide vendors with the ability to perform schema generation. The JPA spec itself does not define schema generation, although most vendors support it, but the annotations and elements, such as @UniqueConstraint, are used exclusively for DDL generation when it is supported. They are not defined for use in validating an existing schema or for anything other than if a vendor supports DDL gen during an early stage of deployment. Some vendors may have chosen to add their own features and interpretations of what a given JPA annotation might mean for validation but this is definitely not according to spec, not portable, and not recommended.

So, given that your uniqueConstraints in @Table will not portably cause any validation at all, and that your hand-rolled validator accesses the database every time anyone touches the attribute, I would not recommend that approach. (I don't think I even want to know how you access the DB given that there is no portable way to access a native JDBC Connection). Depending upon how often it really happens in practice, a better approach might be to just go ahead and optimistically do a flush and handle/look at any resulting exception to see if the db constraint was violated, then report back to the user.


Hi Mike,

Thanks for your reply.

I didn't know that getting the exception would be the good practice. I use Seam with Jboss AS. And, for example, to update a field I just call the flush method of the EntityManager. So I thought that would be good if I avoided to repeat the check of the constraint in a lot of different classes that use this entity and do validation on the entity (centralizing on it). I'm think that maybe I can do something with @prePersist and @preUpdate.

Thanks again Mike.

[[]]'s
Luan
Mike Keith
author
Ranch Hand

Joined: Jul 14, 2005
Posts: 304
We have to be careful not to generalize, but in your case it sounds like taking the optimistic approach and handling a possible exception (much like optimistic locking needs to handle a possible exception) might actually be the preferred approach since your alternative of going to the database for every validation seemed to be a little unwieldy.
Luan Cestari
Ranch Hand

Joined: Feb 07, 2010
Posts: 125

Mike Keith wrote:We have to be careful not to generalize, but in your case it sounds like taking the optimistic approach and handling a possible exception (much like optimistic locking needs to handle a possible exception) might actually be the preferred approach since your alternative of going to the database for every validation seemed to be a little unwieldy.

I will take that approach. Thanks for your help Mike.

[[]]'s
Luan
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: JPA and Composite index
 
Similar Threads
Two PKs
Dealing with composite primary keys
Index
exception related to data constraint
EJB3 Beta Certification - EntityManager BASIC notes. (PART II)