I was talking to my technical lead about extending the code generator, when he suggested to make a suggestion here.
But your point about the other usages of primary keys is a really good reason against my suggested feature. Also, I wasn't aware of the embedded and composite keys. Thanks for your quick reply. </closed> ;) On Tuesday 2 July 2024 at 09:39:57 UTC+2 Lukas Eder wrote: > As an aside, you can always extend the code generator and generate "custom > code sections" like the one in your suggestion: > https://www.jooq.org/doc/latest/manual/code-generation/codegen-custom-code/ > > On Tue, Jul 2, 2024 at 9:38 AM Lukas Eder <[email protected]> wrote: > >> Thanks for your suggestion. >> >> This attempts to address the underlying issue at the wrong place: the >> creation of specific types of predicates, when the feature you're really >> looking for is a type safe representation of a key. With such a type safe >> representation, *all* the key interactions will be type safe, not just the >> creation of predicates. For example, your suggestion doesn't take into >> account the multiple other kinds of predicates that may be interesting to >> form, such as IN predicates, != predicates, NOT IN predicates, etc. >> >> The good news is: we already have that feature! It's called embedded keys: >> >> https://www.jooq.org/doc/latest/manual/code-generation/codegen-embeddable-types/codegen-embedded-keys/ >> >> Once you turn that on, you will never be able to compare keys with scalar >> values anymore. You'll always have to wrap the value(s) in an >> EmbeddableRecord >> >> I hope this helps, >> Lukas >> >> On Tue, Jul 2, 2024 at 9:33 AM Sven Haberer (Schroenser) < >> [email protected]> wrote: >> >>> Feature idea >>> Generate a method like >>> >>> public Condition getPrimaryKeyCondition(String strongly, Integer >>> typed, LocalDateTime parameters) { >>> return >>> FOO.STRONGLY.eq(strongly).and(FOO.TYPED.eq(typed)).and(FOO.PARAMETERS.eq(parameters)); >>> } >>> >>> on each implementation of the Table interface. >>> >>> Benefits >>> This method would allow to write type safe and compile time safe >>> statements that deal with the primary key, for example: >>> >>> int numberOfDeletedRecords = >>> dsl.delete(FOO).where(FOO.getPrimaryKeyCondition(strongly, typed, >>> parameters)).execute(); >>> >>> Also, it gets rid of the boilerplate code of creating the combined where >>> condition, which might be hard to read but easy to mess up for a human >>> developer. >>> >>> -- >>> 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/3496fa39-690a-4fd2-88ff-262b21d6ab9an%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/jooq-user/3496fa39-690a-4fd2-88ff-262b21d6ab9an%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/229fff24-2d92-466a-828c-a870321d39e0n%40googlegroups.com.
