IMO, that’s the important message: “what jOOQ thinks a POJO is. It's a bag of values, not an entity”
As I said, I use DAOs and POJOs only for a demo because I have never found a real-life use case. One of the issues with equals/hashCode is that if I use the POJOs together with some frameworks that use those methods, the current implementation is incorrect in the context of those frameworks. For example, if I use a POJO in a Vaadin Grid and try to refresh the item in the Grid, this will not work because equals will return false after editing the POJO. I had the same issue with the jOOQ Records and therefore created this https://github.com/72services/jooq-utilities I share your opinion that DAOs, POJOs, and Java Records are not the core functionality and are not relevant for jOOQ. And for compatibility reasons, it doesn’t make sense to change anything. > On 23 Oct 2024, at 09:14, Alf Lervåg <[email protected]> wrote: > > I’m partial to the value semantics of records as you describe with the option > of ignoring specific fields. > > Alf Lervåg > >> 23. okt. 2024 kl. 09:10 skrev Lukas Eder <[email protected]>: >> >> I've thought about this again. All 3 options (I'm not seeing others, at >> them moment) come with their own tradeoff. In terms of what jOOQ did >> historically, I think option 1 is the soundest. The rationale is that POJOs >> have always been value types in jOOQ, not entities. Their identity is >> irrelevant, only their contents count. Making the code generator ignore >> non-PK columns in equals() and hashCode() is simply a special case of making >> the code generator ignore *some* columns in equals() and hashCode(), as per >> this related feature request: >> https://github.com/jOOQ/jOOQ/issues/17487 >> >> As such, option 1, where two NULL primary keys would mean the POJOs are >> equal would be consistent with the above #17487 >> >> It would also be consistent with the status quo. Today, if you create a >> table like this: >> >> CREATE TABLE t (i INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY); >> >> You'd get a POJO with only 1 property, which is always NULL prior to >> creation. Today, equals() / hashCode() would completely depend on this >> single property's *value*, so today, two instances of new T() would be >> equal. It seems unwise and surprising to change this "magically" just >> because someone configured an alternative table like this to ignore the j >> column in equals() / hashCode(): >> >> CREATE TABLE t (i INT GENERATED ALWAYS AS IDENTITY PRIMARY KEY, j INT); >> >> Finally, it's important once more to stress what jOOQ thinks a POJO is. It's >> a bag of values, not an entity (as in JPA), even if historically, you can >> have the code generator annotate POJOs with JPA @Entity, @Table, @Column, >> etc. for better interoperability with JPA (a feature that I regret, like >> DAOs...). >> >> Objections? Thoughts? >> >> On Tuesday, October 22, 2024 at 5:06:47 PM UTC+2 Lukas Eder wrote: >> I've summarised it here as well: >> https://github.com/jOOQ/jOOQ/issues/8705#issuecomment-2429525742 >> >> A log statement (assuming a log table) might not have a primary key at all, >> in case of which option 1 really does appear weird. Though, option 1 is >> consistent with https://github.com/jOOQ/jOOQ/issues/17487, where we simply >> include/exclude columns from the implementation. >> >> On Tue, Oct 22, 2024 at 5:03 PM Simon Martinelli <[email protected] <>> >> wrote: >> That’s a tricky question.But I would say they are non-equal. >> You could have two objects with the same content, but you want to store them >> as two records. >> For example, you have a log statement that happened at the same time and >> with the same content. >> >> That’s what I usually implement when using JPA. >> >> >>> On 22 Oct 2024, at 16:51, Lukas Eder <[email protected] <>> wrote: >>> >>> Simon, >>> >>> What's your opinion on the equality of POJOs that don't have a value for a >>> primary key yet (e.g. an identity)? There are at least these 3 strategies: >>> >>> - All not-yet-stored objects are equal >>> - All not-yet-stored objects are non-equal (unless they have the same >>> identity) >>> - Not-yet-stored objects are equal if their contents are equal (current >>> behaviour) >>> >>> My preference would be to treat them all as non-equal >>> >>> >>> On Tue, Oct 22, 2024 at 4:42 PM Lukas Eder <[email protected] <>> wrote: >>> >>> POJOs >>> equals/hashCode use all attributes. Why? >>> If the underlaying database table has a Primary or a Unique key only those >>> attributes should be used. >>> >>> See: >>> https://github.com/jOOQ/jOOQ/issues/8705 >>> <https://github.com/jOOQ/jOOQ/issues/8705> >>> >>> A similar request has come up on that issue where users wish to exclude >>> certain columns from the equals() / hashCode() implementation (e.g. >>> created_at, and other, similar audit columns). That could be implemented in >>> addition to filters for primary keys: >>> https://github.com/jOOQ/jOOQ/issues/17487 >>> >>> I'll do both for jOOQ 3.20. >>> >>> -- >>> 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/CAB4ELO7J6VXBSVfq4ObiAc%2BLVA6o0JdFaBZteqQTdU_yQ%2BHJbA%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/jooq-user/CAB4ELO7J6VXBSVfq4ObiAc%2BLVA6o0JdFaBZteqQTdU_yQ%2BHJbA%40mail.gmail.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/C9399175-44C2-4440-A2EF-5DC46AB0FF2E%40gmail.com >> >> <https://groups.google.com/d/msgid/jooq-user/C9399175-44C2-4440-A2EF-5DC46AB0FF2E%40gmail.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] >> <mailto:[email protected]>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jooq-user/3e95c18d-3a38-495d-8e55-2af93e23cc8bn%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jooq-user/3e95c18d-3a38-495d-8e55-2af93e23cc8bn%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] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jooq-user/D2D734AE-32D4-4E89-9C55-CD7E4FC7D1E3%40lervag.net > > <https://groups.google.com/d/msgid/jooq-user/D2D734AE-32D4-4E89-9C55-CD7E4FC7D1E3%40lervag.net?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/38157A1D-5EB4-4669-9531-779EAFD2F831%40gmail.com.
