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
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jooq-user/3e95c18d-3a38-495d-8e55-2af93e23cc8bn%40googlegroups.com.
