openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Bauer <techhu...@gmail.com>
Subject Re: Best practice to avoid duplicates on @Column(unique=true)
Date Mon, 22 Jun 2009 20:06:36 GMT
Hi Milosz,

Great observation & questions.  The sentence you refer to means that you can
directly invoke a JSR-303 validator at any time from the application.  ex:

        javax.validation.ValidatorFactory factory =
Validation.buildDefaultValidatorFactory();
        javax.validation.Validator validator = factory.getValidator();

        EntityA a = em.find(EntityA.class, "IdOfA");

        Set<ConstraintViolation<EntityA>> cvs = validator.validate(a);

I've only briefly read over how one may create and tie a constraint
validator implementation class to a custom constraint, but I don't see an
immediate way that the constraint validator could get access (outside of
some static helper method) to an em during the validation process.  That
said, I did not read anything in the specs (but, I could easily have missed
something) that would prevent the constraint validator from accessing an em
during application driven validation... so it could potentially be used
during that process.  Care would need to be taken not to cause unintended
side-effects (locks, loading, tx commit/rollback, etc.).

One more thing to keep in mind, application driven validation also requires
a JPA traversable resolver to prevent from validating unloaded or related
entities.  OpenJPA does not provide a resolver, but the plan is to provide
one in a future iteration of 2.0.  Until that is available, validating of
unloaded and related entities (if tagged with @Valid) will occur.

BTW, This scenario will make a great set of test cases.  :-)

-Jeremy


On Mon, Jun 22, 2009 at 12:59 PM, Miłosz Tylenda <mtylenda@o2.pl> wrote:

> Jeremy,
>
> Thanks for the explanation. Maybe you could also explain this sentence from
> the spec:
>
> "Validation can also be achieved by the application calling the validate
> method of a validator
> instance upon an instance of a managed class, as described in the Bean
> Validation specification [8]"
>
> Does it mean we can call validate at whatever time in the persistence
> context? Can we access entity manager then?
>
> Greetings,
> Milosz
>
>
> > 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:
> >
> >
> > 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.
> >
> >
> > 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  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
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message