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:
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.
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.
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
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:
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:
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.
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].
--
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.
