The question whether to put generated code in version control is a controversial one, with no clear winner. There are tradeoffs, pros and cons, see also: https://www.jooq.org/doc/latest/manual/code-generation/codegen-version-control/
See also this interesting discussion: https://twitter.com/lukaseder/status/1805209257295393167 I agree though that if generated code is being checked in, any potential conflict can be ignored as it is just derived from a different conflict elsewhere (e.g. the DDL). On Thu, Aug 29, 2024 at 8:51 AM Dominik Hirt <[email protected]> wrote: > Why your JOOQ generated source files (as e.g. your POJOS) are within a git > merge request ? > No JOOQ generated source file needs to be checked into your repo due to > it's generated automatically for every build. > And if you call > mvn generate-sources or mvn clean generate-sources > after every DB Schema modification, then your (record based) POJOS alway > match your DB Schema. > Such workflow did also a great job together with some DB migration tolls > like Liquibase or Flyway: simple call > > mvn liquibase:updateTestingRollback generate-sources > > for every modification of your DB Schema. If the output of the two maven > plugins is too noisy, you can reduce the clutter by > > mvn liquibase:updateTestingRollback generate-sources > -Dorg.slf4j.simpleLogger.log.org.liquibase=warn > -Dorg.slf4j.simpleLogger.log.org.jooq=warn > > Hope that helps > Dominik > [email protected] schrieb am Mittwoch, 28. August 2024 um 20:47:55 > UTC+2: > >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/c84d38d0-d478-46b5-bf34-717c92bfcbe4n%40googlegroups.com > <https://groups.google.com/d/msgid/jooq-user/c84d38d0-d478-46b5-bf34-717c92bfcbe4n%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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jooq-user/CAB4ELO5vAvtmFYK0AsSjtS8ANd9Tcc4QJZ2rcLzHbrDaO-11ow%40mail.gmail.com.
