-
Notifications
You must be signed in to change notification settings - Fork 106
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
@JsonIgnoreProperties not working with lazy loaded objects #78
Comments
Actually, I suspect this may be same as #70, as FasterXML/jackson-databind#1060 so that perhaps such improvement could be added. EDIT: as of October 2018, above-mentioned issue 1060 has been implemented so this feature DOES work for non-Hibernate Collections. |
Nop i can reproduce the issue with a user -> manager relationship (many to one, optional). Here's is a github sample project https://github.com/walfrat/jackson-ignore-properties-lazy-objects Some explanation are required : I have a weird test classes with one init method that is annotated @test : to setup the data in another transaction (@before is in the same transaction). So to test the thing you have to run the whole class (and init has to get called before the other testSerialize). The result : {"id":12,"name":"user","address":"address","manager{"id":27,"name":"user","address":"address","manager":{"id":25,"name":"manager","address":"ADDRESS THAT SHOULD NOT BE SHOWN","manager":null,"anotherManager":null},"anotherManager":{"id":26,"name":"eager manager","manager":null,"anotherManager":null}} With an ignore properties on address fields for both of manager and anotherManager fields In my project i have the problems with some no-optional relations that has the same problem too. |
can't edit : the result is {"id":27,"name":"user","address":"address","manager":{"id":25,"name":"manager","address":"ADDRESS THAT SHOULD NOT BE SHOWN","manager":null,"anotherManager":null},"anotherManager":{"id":26,"name":"eager manager","manager":null,"anotherManager":null}
} |
I wonder if part of the issue could be due to #81, which I just fixed? Or... actually, more likely, one of remaining issues with Proxy handling. |
Nop still the same after upgrade to 2.7.0-rc3. I don't think it could be related to TypeErasure since the problem can 2016-01-05 19:03 GMT+01:00 Tatu Saloranta notifications@github.com:
|
@walfrat Thank you for verifying this. Fix would likely then require complete rehaul of proxy handling, something that should be done, but won't be done before 2.8. |
Any news about this ? |
Still no fix on sight? |
At this point there will only be a fix if someone contributes a fix. I do not use Hibernate and am not familiar with its implementation details regarding Proxy handling. So it would be up to someone with more Hibernate knowledge; I can help with Jackson/Collection handling side if necessary. |
Hello,
I'm using JsonIgnoreProperties to prevent some fields to get serialized on my getters method, it works for eagerly loaded objects but not for lazy loaded objects.
I upgraded to the latest version of jackon (2.6.3) and same for datatype-hibernate and moved the @JsonIgnoreProperties from the getter to the fields and adding the allowSetters = true but i still get the problem.
I didn't check for all @To but at the moment i can confirm that it doesn't work for lazy ManyToOne relation. But i don't end up with a cyclic conflict.
Exemple : i have a class A which have a eagerly loaded list of B elements. B has lazy loaded A element. Each have a JsonIgnoreProperties which exclude the other one to be serialized
For one special case i query directly B elements and want to lazy-load A. The JSOn end up with A being full serialized in B but B elements in A don't serialize A again.
Then i end up with the following JSON
[{
_type:"B";
a:{
_type:"A"
b:[{
_type:"B"
/* no a element */
}, ...],
[...]
}]
}
}]
Exemple of Code for A/B :
class A{
@JsonIgnoreProperties({"a"}, allowSetters=true)
@onetomany(fetch=FetchType.EAGER)
Set b;
}
class B{
@JsonIgnoreProperties({"b"}, allowSetters=true)
@manytoone(fetch=FetchType.LAZY)
A a;
}
Environment :
The text was updated successfully, but these errors were encountered: