JSR-303 and JPA overlapping

3
votes

Aloha hey!

I already use JPA annotations, now I'd like to use JSR-303 annotations to validate attributes as well.

My questions is, how well do they interact with each other?
If I use @Basic(optional=false) or @NotNull, will I still have to use nullable=false etc.?

I haven't decided which validator implementation to use, e.g. hibernate-validator or oVal (You may also suggest others. I know that oVal is not a JSR-303 implementation, but it maps most annotations).

oVal manual (see above) states that certain JPA annotations will be translated into oVal annotations as well. Hibernate-validator has a similar mechanism.

Some search results claim that Bean Validation and JPA do officially overlap, but I have not figured in which exact way.

2
javajpabean-validation

2 Answers

6
votes

They are both run time checks . There is some difference though
JPA specification states @Basic(optional = false) can be use as schema hint i.e if you are updating your database schema by JPA (generally not a good practice though) you can use it to indicate that this column value can not be null and must have a value.

Section 9.1.18 Basic Annotation of JPA1 specification
and
Section 11.1.6 Basic Annotation of JPA2 specification

Clearly indicate that.

Other than that both will do a runtime check in other words before the sql is send to database.
Generally for validation prior to sending SQL to server if you are using JSR 303 which includes many other checks as well you will use @NotNull however you may not be using JSR 303 in which case you can use @Basic(optional = false) which has been out even before JSR 303 however is not preferred over JSR303.
You might now want to know @Column(nullable = false) is purely used on database side.
Should you ever use both - Yes only if you are allowing JPA to update schema otherwise JSR-303 is preferred over the other.

-1
votes

After reading both specifications almost entirely, this is what I found.

I'll thusly answer my question myself;
As of now;

  • JPA and BV annotations do often share the same meaning. The usage of BV constraints however does not influence the created DDL schema constraints of the JPA implementation.

  • The JPA implementation will, if configured so, check BV constraints at pre-persist, pre-update, and pre-remove. This is done by delegating the work to the BV implementation. The BV implementation on the other hand will not use JPA constraints.

  • Using BV constrains such as @NotNull to automatically cause JPA constraints such as @Column(nullable=false) is recommended to the JPA implementation in the BV specification, but not part of the official specification and thus not reliable behaviour.

As a result I will have to use both BV and JPA annotations, even though they may have the same meaning.

References

P.S.: I will wait whether someone has any corrections or additions to this, then set is as the preferred answer.