Hello Dominik and Lukas, you are both right about that if i use the generated code as-is (either by not checking it into git, or by letting it reside in the "generated"-folder) i would not run into my described problem
- If checked in, the mergers could just assume that the code in the "generated"-folder is ok as auto-generated and would not need to be reviewed. - If not checked in, there would be no problem as it does not show in the merge at all. --- Lukas assumption in his last comment is correct. - My use-case is, that i need to hand-write my POJOs in a way to match the generated code My use-case is described as follow as example with a new database-table: - 1. i create a liquibase-migration that creates the new database-table(s) - 2. i run the jooq-codegenerator which creates the Pojos for those new database-table(s) - 3. i copy the Pojos from the "generated"-folder into the project "source"-folder - 4. i now change the Pojos in the "source"-folder by adding relationships between the Pojos to create a "nested" structure that reflects the database-relationships (i rename the Pojos to DTOs also) - 5. The so created DTOs need to be Serializable by Jackson to create JSON and return this nested-json to the Frontend for consumption. This would be one of the typical use-cases why i need to hand-write my POJOs (DTOs) and not use the generated code for all my use-cases (only for some). - If The database-table(s) are changed now, i need a way to detect that i need to change my handwritten Pojos to be noticed of those changes. - For this i let my handwritten Pojos implement the jooq generated Interfaces, which work great so far! - Sadly the Getters / Setters in my handwritten Pojos need to be reviewed by the Mergers and i search for a way to make my handwritten pojos more simple, while still be noticed of changes. ---- The best solution would be to use as less handwritten code as possible, but for now i see no way to get rid of the hand-written pojos, so i seek for a way to get rid of the getters / setters. Java14 Records of Frameworks like "Lombok" seem to be able to help here. But it's not really an important problem to me, - it's only a small nuisance, which is also totally fine to work with :) lukas...@gmail.com schrieb am Donnerstag, 29. August 2024 um 07:07:32 UTC: > Thanks for your message, Bernd, > > Well that "specification" that you're talking about is just the previous > version of your schema. You could generate interfaces from your schema with > jOOQ (use the <interfaces/> flag) in a code generation run 1, then in code > generation run 2, re-generate the records, and try to compile them against > the previously generated interfaces. You can add interfaces to any > generated class using generator strategies, e.g.: > > https://www.jooq.org/doc/latest/manual/code-generation/codegen-matcherstrategy/ > > This does what you're asking for. > > But I'm not really sure I understand the underlying use-case here. Is this > because you would like to hand-write your POJOs in a way to match the > generated code, but for some reason, *not* use the code generator for this? > > On Wed, Aug 28, 2024 at 8:47 PM 'Bernd Huber' via jOOQ User Group < > jooq...@googlegroups.com> wrote: > >> I want to ask about the ".withRecords(true)" Functionality of the >> Jooq-Codegenerator... >> >> - is it possible to let those Pojos (which are generated as >> java14-records) adhere to some specification, that makes sure that whenever >> the db-table-schema changes i get a error in my IDE to see that i need to: >> - add a field >> - remove a field >> - rename a field >> >> With specification a Java-Interface would be optimal. >> >> I guess the Java-Interface should work if it defines the default-getters >> of the java14-records. >> >> For example: >> >> public interface PersonSpec { String name(); int age(); } >> >> public record Person(String name, int age) implements PersonSpec { >> // No additional methods needed; the record already provides them. >> } >> >> >> --- >> >> i currently think about using java14-Records instead of normal Pojos >> (with getters/setters) because the getters/setters can be harder to review >> in merge-requests. The getters/setters are often so much code that the >> review-person in the merge-request has much to review, while it would only >> be fields. >> >> But i don't want to loose the advantage of letting the Pojo implement and >> interface, which makes sure that if my db-table changes its schema i am >> forced to also fix the Pojo for that. >> >> -- >> > 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. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/jooq-user/c2fa6bd1-d999-452c-8a15-80a481680d90n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jooq-user/c2fa6bd1-d999-452c-8a15-80a481680d90n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/fe62b1c5-65da-49d6-9874-2923330f4cd5n%40googlegroups.com.
