New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Accomodate domain object identity in @EqualsAndHashCode #105

Closed
lombokissues opened this Issue Jul 14, 2015 · 7 comments

Comments

Projects
None yet
2 participants
@lombokissues
Collaborator

lombokissues commented Jul 14, 2015

Migrated from Google Code (issue 32)

@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

👤 lhoriman   🕗 Aug 18, 2009 at 01:34 UTC

For JPA domain objects (classes annotated with @ Entity), equality is best defined as:

  • Are the classes equal
  • Are the ids equal

The id of a JPA entity will either be:

  • A compound of all the fields annotated with @ javax.persistence.Id
    or:
  • The single field annotated with @ javax.persistence.EmbeddedId

Some things to consider:

  • @ Id and @ EmbeddedId annotations might come from superclasses.
  • It might also be a good idea to have the @ EqualsAndHashCode(include={"xxx"}) option as well
    since it's still possible for (masochistic) developers to define the ids and relationships in XML.
    And it's a useful construct in general.
  • You might want this to only apply to @ Entity objects.
Collaborator

lombokissues commented Jul 14, 2015

👤 lhoriman   🕗 Aug 18, 2009 at 01:34 UTC

For JPA domain objects (classes annotated with @ Entity), equality is best defined as:

  • Are the classes equal
  • Are the ids equal

The id of a JPA entity will either be:

  • A compound of all the fields annotated with @ javax.persistence.Id
    or:
  • The single field annotated with @ javax.persistence.EmbeddedId

Some things to consider:

  • @ Id and @ EmbeddedId annotations might come from superclasses.
  • It might also be a good idea to have the @ EqualsAndHashCode(include={"xxx"}) option as well
    since it's still possible for (masochistic) developers to define the ids and relationships in XML.
    And it's a useful construct in general.
  • You might want this to only apply to @ Entity objects.
@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

👤 reinierz   🕗 Aug 18, 2009 at 12:07 UTC

This is going to be rather complicated. Full discussion is here:

http://groups.google.com/group/project-lombok/browse_thread/thread/b0e6a34d1bc72526

Collaborator

lombokissues commented Jul 14, 2015

👤 reinierz   🕗 Aug 18, 2009 at 12:07 UTC

This is going to be rather complicated. Full discussion is here:

http://groups.google.com/group/project-lombok/browse_thread/thread/b0e6a34d1bc72526

@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

👤 reinierz   🕗 Sep 01, 2009 at 23:45 UTC

We'll support it via include, as triggering on @ Id/@ EmbeddedId has far too many complications (see previous
link).

Collaborator

lombokissues commented Jul 14, 2015

👤 reinierz   🕗 Sep 01, 2009 at 23:45 UTC

We'll support it via include, as triggering on @ Id/@ EmbeddedId has far too many complications (see previous
link).

@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

👤 jnorris10   🕗 Sep 02, 2009 at 16:02 UTC

Defaulting JPA entities to base their equality on @ Id/@ EmbeddedId does not seem like a good idea. Entities
often have a "natural" identifier which is separate from @ Id. In this case, @ Id is used as a surrogate key (making
it easier to manage ORM mapping and refactor the DB schema later). Another advantage is it lets the natural
constraints be enforced in the domain model independent of the persistence mechanism used. Also, in cases
where @ Id is generated from the DB, it allows objects to have a valid notion of equality before they are persisted.

I agree with reinierz, an explicit include properties mechanism is best here. It's the most clear and simple.

Collaborator

lombokissues commented Jul 14, 2015

👤 jnorris10   🕗 Sep 02, 2009 at 16:02 UTC

Defaulting JPA entities to base their equality on @ Id/@ EmbeddedId does not seem like a good idea. Entities
often have a "natural" identifier which is separate from @ Id. In this case, @ Id is used as a surrogate key (making
it easier to manage ORM mapping and refactor the DB schema later). Another advantage is it lets the natural
constraints be enforced in the domain model independent of the persistence mechanism used. Also, in cases
where @ Id is generated from the DB, it allows objects to have a valid notion of equality before they are persisted.

I agree with reinierz, an explicit include properties mechanism is best here. It's the most clear and simple.

@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

👤 lhoriman   🕗 Sep 02, 2009 at 16:07 UTC

I think everyones on the same page - an "include" member of the @ EqualsAndHashCode annotation would be
great.

Collaborator

lombokissues commented Jul 14, 2015

👤 lhoriman   🕗 Sep 02, 2009 at 16:07 UTC

I think everyones on the same page - an "include" member of the @ EqualsAndHashCode annotation would be
great.

@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

👤 reinierz   🕗 Sep 02, 2009 at 23:47 UTC

addressed in f1124aa which will be rolled out in v0.8.5. The
'includes' parameter is called 'of', so you could do:

@ EqualsAndHashCode(of="id")
@ Entity
public class SomePersistedClass { ... }

We've also added fields that start with $ as default excludes. Lombok's own @ Synchronized can generate
these fields, and I expect other automated tools will as well. $ is understood to mean 'generated', and it
seems safer to exclude them by default.

Collaborator

lombokissues commented Jul 14, 2015

👤 reinierz   🕗 Sep 02, 2009 at 23:47 UTC

addressed in f1124aa which will be rolled out in v0.8.5. The
'includes' parameter is called 'of', so you could do:

@ EqualsAndHashCode(of="id")
@ Entity
public class SomePersistedClass { ... }

We've also added fields that start with $ as default excludes. Lombok's own @ Synchronized can generate
these fields, and I expect other automated tools will as well. $ is understood to mean 'generated', and it
seems safer to exclude them by default.

@lombokissues

This comment has been minimized.

Show comment
Hide comment
@lombokissues

lombokissues Jul 14, 2015

Collaborator

End of migration

Collaborator

lombokissues commented Jul 14, 2015

End of migration

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment