JOOQ codegen failes NOT NULL javax validation for auto generated key or default values

[William Zhang]

Hi ALL,

Question is HOW do we handle the validation for @NotNull columns with default values or auto-generated key values in JOOQ?

Not sure whether it's a known issue. For generated POJOs, JSR annotation for auto generated ID is set as @NotNull, which sounds perfect. E.g.

Database -

CREATE TABLE `change_log` (

  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,

  `log` varchar(1023) CHARACTER SET utf8 COLLATE utf8_unicode_ci DEFAULT NULL,

  `date_created` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_unicode_ci;  

POJO ChangeLog.java -

@NotNull 

public UInteger getId() {};

JSON request -

{

    "log" : "this is a log test"

}

 

API resource -

public Response createJsonChangeLog(@Valid ChangeLog changeLog) {}

However, the validation will fail in javax validation, as the JSON request will not contain id or creation date, which will be generated in the sql transaction. Therefore you will receive 400 bad request error - Id may not be null.

Thanks,

William 

[Lukas Eder]

Hi William,

Thank you very much for bringing this to our attention. Unfortunately, Java doesn't have a way of distinguishing NULL (as in uninitialised) from NULL (as in defaulted). And neither does javax.validation. We've fixed issues in the past where in the event of both NOT NULL constraint and DEFAULT specification being present on a database column, we prefer the DEFAULT specification.

I suspect that this was an oversight in the case of javax.validation annotations, which shouldn't be generated in this case.

I've registered an issue for this. We'll fix this ASAP:

https://github.com/jOOQ/jOOQ/issues/5128

Thanks again,

Lukas

--
You received this message because you are subscribed to the Google Groups "jOOQ User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jooq-user+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[wil...@honestbuildings.com]

Awesome. Thanks for your prompt response. When could we expect the release of 3.8.0?

Another thing is that I wanna mock myEntityDao.insert(...) to test post methods instead of MockProvider or checking DSL query. However, all insert methods in DAOImpl.java are final and can't mocked... Is there any reason to make them final (and void)? Can we remove the final keyword as what you did for #4855?

Let me know if you want me to give more explanation or post this to a separate email chain.

Thanks,

William

[Lukas Eder]

Hi William,

2016-03-09 1:12 GMT+01:00 <wil...@honestbuildings.com>:

Awesome. Thanks for your prompt response. When could we expect the release of 3.8.0?

Early Q2 2016. Hopefully by beginning of April. The only high prio element remaining on the roadmap is DB2 for z support. Unfortunately, a bit of a tough item...

 

Another thing is that I wanna mock myEntityDao.insert(...) to test post methods instead of MockProvider or checking DSL query. However, all insert methods in DAOImpl.java are final and can't mocked... Is there any reason to make them final (and void)? Can we remove the final keyword as what you did for #4855?

You can upgrade to jOOQ 3.7.3:

https://github.com/jOOQ/jOOQ/issues/4864

Curious: What's the issue with void, there?

 

Let me know if you want me to give more explanation

Yes! Understanding the bigger context is always good :)

 

or post this to a separate email chain.

No, this works fine.

Cheers,

Lukas