49

I have an entity annotated with @Entity.
If I am responsible for creating the CREATE TABLE scripts why should I specify @Column( nullable = false ) when I can create a column in the database with the NOT NULL keywords? Is there any example that shows the benefits of using this property in a field?

Manuel Drieschmanns
  • 704
  • 5
  • 26
Fagner Brack
  • 2,365
  • 4
  • 33
  • 69

3 Answers3

59

Better error messages and error handling, especially if you also add the JSR303 @NotNull annotation.

If you create the column as NOT NULL but don't tell JPA it's not null, JPA will assume that null values are OK. When you try to save an object with nulls, it'll proceed to send that to the DB and you'll get a DB level error. This increases log spam in the database and it's much harder to determine from the error which column(s) of which table(s) were the problem, let alone map them back to their JPA names.

If you annotate them as not null, JPA will throw an exception before saving, avoiding DB log spam and usually giving you a better error. In particular, if your JPA provider supports JSR303 and either translates nullable=false into @NotNull internally or you've added @NotNull too, it'll give you a data structure you can examine to see exactly what fields of what objects were rejected for what reasons, along with customisable templated error messages.

That's why you should tell JPA about NOT NULL fields. That, and it's easier for others working on your code to understand without also having to read the DB schema.

Kwadz
  • 2,206
  • 2
  • 24
  • 45
Craig Ringer
  • 307,061
  • 76
  • 688
  • 778
  • 1
    ok, but it's unclear in your answer whether you think there is an added value in having both @NotNull and @Column(nullable = false). What do you think? – ymajoros May 08 '13 at 10:53
  • 1
    @ymajoros Depends a bit on how smart your JSR303 / JPA integration is. I tend to put both in but a good JPA JSR303 integration would add an implicit NotNull for columns that're nullable=false – Craig Ringer May 08 '13 at 11:53
  • 3
    Should they? If it's not part of the spec, I don't see why and in which context. I'd rather have @NotNull but no nullable=false, because the latter is jpa only. My question is more about the added value of @Column(nullable=false). – ymajoros May 08 '13 at 14:27
34

Additionally, if your column has nullable = false in @ManyToOne annotation, Hibernate does INNER JOIN query to the related table. nullable = true gives in result LEFT JOIN.

That is other difference.

Mohammad Faisal
  • 5,783
  • 15
  • 70
  • 117
Adam Tychoniewicz
  • 648
  • 6
  • 7
4

In your case there might not be actual benefit, but:

  • if you are using your jpa provider to generate your schema (either via maven or via automatic generation like hbm2ddl.auto), then it matters
  • if you configure your jpa provider to validate the schema against the entity model, then you need them to be in sync.
Bozho
  • 588,226
  • 146
  • 1,060
  • 1,140
  • The first assumption can be ignored because `hbm2ddl.auto` is not meant for production and I am testing my project with maven and a managed JBoss instance with Arquillian. About the second thing it would be useful only to validate my schema then? In this case I believe the verbosity it brings is not worth it, unless there is a better reason than those. – Fagner Brack Mar 03 '13 at 02:09
  • 2
    having your entity model and the db schema in sync is important. You might not use it now, but later you may add tools that need it. Related http://techblog.bozho.net/?p=1100 – Bozho Mar 03 '13 at 07:09