Skip to content
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

Complex objects issue #211

Closed
niclarcipretti opened this issue Sep 28, 2015 · 8 comments
Closed

Complex objects issue #211

niclarcipretti opened this issue Sep 28, 2015 · 8 comments
Assignees
Labels

Comments

@niclarcipretti
Copy link

@niclarcipretti niclarcipretti commented Sep 28, 2015

Hi,

I'm experiencing major performance issues when trying to audit complex objects with Javers.
The main problem is that Javers gets the whole object with all its dependencies, and if those dependencies has other dependencies, it falls into an endless recursion that takes a lot of time. I was wondering if is there any way to make Javers record just the FK values for the dependencies instead of the whole nested object?

I'll try to clear that with an example:

Entity User
-Long id
-String login
-Person person

Entity Person
-Long id
-String name
-User registerUser

The tables would be like this:

User
-id PK
-login
-personId FK

Person
-id PK
-name
-userId FK

If I audit User, Javers will try to fetch the whole person, which has another user, that has another person, and this will go on and on untill the end of the recursion. Combine that with hibernate's lazy initialization of those dependencies, and we will have a bottleneck in the transaction.
What I need is: if try to audit User, Javers get the User object, with its person having only the id attribute filled, ignoring the rest of the object, that, for User auditing, it's useless information.

What you guys think about this?

Cheers

Nick

@bartoszwalacik
Copy link
Member

@bartoszwalacik bartoszwalacik commented Sep 28, 2015

Quick answer : use @DiffIgnore on those properties you dont want to audit and Javers wont follw them

@niclarcipretti
Copy link
Author

@niclarcipretti niclarcipretti commented Sep 28, 2015

Hi @bartoszwalacik,

I can't do that, cause I need to know if the relation has changed (e.g the User's Person has changed).

What do you suggest? In your opinion, is this a weird use case?

Cheers

Nick

@bartoszwalacik
Copy link
Member

@bartoszwalacik bartoszwalacik commented Sep 29, 2015

take a look at #189
would it solve your problem?

@niclarcipretti
Copy link
Author

@niclarcipretti niclarcipretti commented Sep 29, 2015

Not really. I don't need depth control. I need no depth at all. I think the best solution would be something like: @DiffIgnore(logId = true) where it would ignore the object and just log the id. So, when I retrieve it from Mongo, I just have to lazy initialize the object fetching it by its id.
Too confusing? What is your opinion?

Cheers

Nick

@bartoszwalacik
Copy link
Member

@bartoszwalacik bartoszwalacik commented Sep 30, 2015

well, it could be done, think better name for this kind of annotation would be @ShallowReference

So JaVers would only log reference changes for this property but would stop building object graph from it. This ann could also work on class level.

Looks like it's not very hard to implement, maybe you could think about some contribution? I'm quite busy now with older isues waiting in the backlog ...

@floresek
Copy link

@floresek floresek commented Oct 1, 2015

@bartosz - additional property for @ShallowReference could be usefull - persistIfNotExists

If true, javers should persist the referenced object (so the whole referenced object should be passed)

if false - only referenced object id. If the object does not exists in javers DB, the exception should be thrown (only @id of referenced object should be passed).

@bartoszwalacik
Copy link
Member

@bartoszwalacik bartoszwalacik commented Oct 1, 2015

so maybe you take look at javers codebase and consider contributing this feature? it shouldn't be very hard, and I can help if you approach some difficulties...

@bartoszwalacik bartoszwalacik added this to the release 1.3.8+ milestone Oct 12, 2015
@akrystian akrystian self-assigned this Oct 25, 2015
akrystian added a commit that referenced this issue Nov 22, 2015
akrystian added a commit that referenced this issue Nov 23, 2015
akrystian added a commit that referenced this issue Jan 10, 2016
akrystian added a commit that referenced this issue Jan 14, 2016
Conflicts:
	javers-core/src/main/java/org/javers/core/metamodel/annotation/AnnotationNamesProvider.java
	javers-core/src/main/java/org/javers/core/metamodel/annotation/AnnotationsNameSpace.java
	javers-core/src/main/java/org/javers/core/metamodel/annotation/ClassAnnotationsScanner.java
	javers-core/src/main/java/org/javers/core/metamodel/annotation/JPAAnnotationsNameSpace.java
	javers-core/src/main/java/org/javers/core/metamodel/annotation/JaversAnnotationsNamesSpace.java
	javers-core/src/main/java/org/javers/core/metamodel/type/ManagedClassFactory.java
akrystian added a commit that referenced this issue Jan 14, 2016
akrystian added a commit that referenced this issue Jan 20, 2016
bartoszwalacik added a commit that referenced this issue Jan 23, 2016
bartoszwalacik added a commit that referenced this issue Jan 23, 2016
@bartoszwalacik bartoszwalacik added documentation and removed review labels Jan 23, 2016
akrystian added a commit that referenced this issue Feb 7, 2016
@bartoszwalacik
Copy link
Member

@bartoszwalacik bartoszwalacik commented Feb 12, 2016

see new @ShallowReference ann, released in JaVars 1.4.11

http://javers.org/documentation/domain-configuration/#class-level-annotations

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.