David & Milosz, Based on the information provided, I do not think Bean Validation would provide a good solution for this problem. Used within the context of JPA, bean validation gets called when various lifecycle events occur; pre-persist, pre-remove, pre-update. In order to create a custom validation constraint, you'd likely need to invoke some database operations (likely some variant of the query Craig suggested). Regarding the use of em & query operations inside lifecycle events JPA specification states:
<spec> In general, the lifecycle method of a portable application should not invoke EntityManager or Query operations, access other entity instances, or modify relationships within the same persistence context.[38] A lifecycle callback method may modify the non-relationship state of the entity on which it is invoked. </spec> So using database operations, at least within the same persistence context, probably isn't a good idea. Regardless, I think the net result would be that, application-wise, you'd be back in the nearly same situation as present. The exception would still occur on the persist, the main difference would be that the exception would be coming from the validator instead of the failed database operation. -Jeremy On Sat, Jun 20, 2009 at 3:30 AM, Miłosz Tylenda <mtyle...@o2.pl> wrote: > David, > > Apart from what Craig has suggested, what came to my mind is that there is > an ongoing effort to implement JSR-303 Bean Validation in OpenJPA 2.0. Not > sure however, whether it is sufficiently implemented yet and it can be used > for your purpose. Might be worth checking though. > > Cheers, > Milosz > > > I realise that this is not strickly an OpenJPA problem, rather a more > > general JPA one, but there are experts here who might know the answer. > > > > I have a number of classes which represent tables which have not only > > an Id field, but also various other fields which are marked as unique. > > > > When I persist and then try to flush a new object which has a non-unique > > value in the object (the user entered bad data) it breaks the transaction > > and throws an error. All of which is quite understandable. > > > > The question is what is the best way to avoid it. Do I have to build the > > checking into the application, or is there a more generic way which I > > can use as a validation technique before I try to persist the object. > > > > David > > >
