1

We do have a Web application using JPA with an Oracle database. In many occassions the tables are defined with NOT NULL clauses for some fields. Sometimes we use the JPA @NotNull annotation. We realized that the code for the entities does not match 100% in all cases with the DB tables using the NOT NULL clauses (our DB is changing quite often and then it is not 100% synced with the code in this aspect).

We realized that using @NotNull has good advantages for controlling for example validation in JSF, however it could also have many side effects.

In our project our entities are organized as a hierarchy of classes sharing common fields. With this settings in mind, imagine someone is changing one field in a base entity to @NotNull. This little change will affect many screens and those failures will only be detected at execution time (unless you have an exhaustive testing approach in place).

Now, the question is, what is the suggested way for handling this issue? Is it better to use JPA entities without any kind of hierarchy, even though many fields must be coded again and again?

narko
  • 3,645
  • 1
  • 28
  • 33
  • 1
    @NotNull is the standard way to do this, I highly recommend use it. As for your problem, maybe your team can try using "@PrePersist" and "@PreUpdate" entity events, in this case every time someone include an "@NotNull" annotation which would not be evaluated in olders screens then the developer can insert some default value for these fields inside the methods controlled by "@PreUpdate" and "@PrePersist". – Bonifacio Nov 18 '15 at 17:05
  • 1
    NotNull might influence the choices that the persistence provider makes under the hood when generating SQL, for example choosing to do an inner join or an outer join. I would make sure to have them. Its a maintenance bother for sure, but nobody ever said that using an ORM would take away the need to meticulously verify the meta data. You could automate that process, checking entity property annotations against the database meta data to see if they match up. – Gimby Nov 18 '15 at 17:26
  • 1
    I found the following piece of information about @NotNull here: http://stackoverflow.com/questions/7439504/confusion-notnull-vs-columnnullable-false **@NotNull is a JSR 303 Bean Validation annotation. It has nothing to do with database constraints itself. As Hibernate is the reference implementation of JSR 303, however, it intelligently picks up on these constraints and translates them into database constraints for you, so you get two for the price of one.** – narko Nov 19 '15 at 08:39
  • This means that someone could be tempted to control everything from code and not update the constraints in the DB schema. I believe some kind of mechanism to keep code and DB synced is a must in order to avoid misunderstandings. – narko Nov 19 '15 at 08:41
  • @narko crud, I was thinking and talking about the 'nullable' attribute, not the NotNull annotation. – Gimby Nov 19 '15 at 11:47
  • To put it simple: `@NotNull` validates at entity model level whereas `@Column(nullable=false)` validates at database level. – wypieprz Nov 19 '15 at 21:27

0 Answers0