I'm creating an application and I'm a bit confused about the current state of jOOQ. It's my first time using jOOQ for everything including CRUD so I might be missing some stuff.
I know DAOs and probably Pojos are getting deprecated, however, I can't wrap my head around how to deal with this in a Database First Design.
The easiest thing I can do is create my own Pojos but then we are back to the usual JPA Entity files, which will not map correctly with the Record if the database has changed.
1) Does deprecating generated pojos imply that I will have to use my own Pojo source generator in the future?
2) Should I have a custom mapper that will throw an exception when Pojo can't map fields with the Record object?
3) Is the best approach to keep using the generated pojos for now? It's not a huge application but I have to pick a strategy and use it in most of the database services.
The default way to do CRUD in jOOQ is to use the UpdatableRecord classes produced by the code generator. See also: https://www.jooq.org/doc/latest/manual/sql-execution/crud-with-updatablerecords
Pojos aren't getting deprecated. The issue description of #5984 was outdated, the comments were more up to date. I've updated the issue description to reflect this.
1) Does deprecating generated pojos imply that I will have to use my own Pojo source generator in the future?
No, see above.
2) Should I have a custom mapper that will throw an exception when Pojo can't map fields with the Record object?
That depends what your pojos should do. If you use jOOQ's generated ones, then the out of the box DefaultRecordMapper will always be able to map them
3) Is the best approach to keep using the generated pojos for now? It's not a huge application but I have to pick a strategy and use it in most of the database services.
You probably don't need POJOs, UpdatableRecord will be enough in most cases. POJOs are there to allow for transferring data without any jOOQ dependency, e.g. between servers.