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

Avoid nested DiffIgnored ValueObject being compare #443

Merged
merged 2 commits into from Oct 23, 2016

Conversation

Projects
None yet
2 participants
@hank-cp
Contributor

hank-cp commented Oct 17, 2016

Set gsonBuilder exclusionStrategies to avoid nested ValueObject circular reference.

@bartoszwalacik

This comment has been minimized.

Member

bartoszwalacik commented Oct 18, 2016

why this strategy? javers doesn't serialize user's domain objets

@hank-cp

This comment has been minimized.

Contributor

hank-cp commented Oct 19, 2016

Sorry, I didn't explain this issue clear enough. The problem is not about comparison, but about committing against MongoRepository. I add a few test case, hope that would explain the problem.

@bartoszwalacik

This comment has been minimized.

Member

bartoszwalacik commented Oct 19, 2016

interesting, so, it's more gson problem than javers issue

@bartoszwalacik

This comment has been minimized.

Member

bartoszwalacik commented Oct 19, 2016

you have a wrong mapping for CrossReferenceObjectA.
Obviously, this is a complext object so you should map it as ValueObject (not Value)
It's enough to remove @value ann, see
7ee9f6d

@bartoszwalacik

see comments

@hank-cp

This comment has been minimized.

Contributor

hank-cp commented Oct 22, 2016

@bartoszwalacik Actually I do need to mark CrossReferenceObjectA/B as @Value, three reasons in my thought:

  1. In my case, CrossReferenceObjectA/B are very general, fundamental class, most of other business class will refer them, and they change quite a lot and often.
  2. These objects basically have a little bit complex, cross reference relation graph, according to my observation, committing them as @ValueObject, the javers repository size will be glowing very fast, a little bit out of control.
  3. I have to implement CustomPropertyComparator for these classes so it could compare by my custom algorithm rather than Javers general comparison algorithm. I think this will required @Value or JaversBuilder.javers().registerValue() (correct my if I am wrong).
@bartoszwalacik

This comment has been minimized.

Member

bartoszwalacik commented Oct 22, 2016

Ok, makes sense, if @value fits better to your model then you should be able to choose it. Give me a while and I will merge

@bartoszwalacik bartoszwalacik merged commit c473296 into javers:master Oct 23, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bartoszwalacik

This comment has been minimized.

Member

bartoszwalacik commented Oct 26, 2016

released in 2.5.0

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