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

Cyclic mapping defense #2

Closed
slemesle opened this Issue Feb 19, 2014 · 1 comment

Comments

Projects
None yet
2 participants
@slemesle

slemesle commented Feb 19, 2014

Selma should either forbid cyclic mapping by failing at compile time or
have a smarter way.

Selma should never go in eternal mapping loop in such condition.

Bean A contains a bean B which contains original A.

@slemesle slemesle added enhancement and removed enhancement labels Feb 19, 2014

@jandsu

This comment has been minimized.

Show comment
Hide comment
@jandsu

jandsu Jun 16, 2015

I had solved this in a former homegrown solution.
If this can help, what I ended up with was a cache:
[target class + source reference => target reference]
which I had implemented using:
HashMap<Class<TARGET>, HashMap<SRC, TARGET>>

The rationale for the target class was that the same "source" could be mapped twice in the DTO tree. The reason for not using an IdentityHashMap was that our underlying lib above JPA would possibly generate several instances for the same row in the database...

The cache only lived inside a top level conversion from the user... (it was cleared as soon as the conversion returned to the user). In other words, if I had a Person with an Address (both translating to PersonDto and AddressDto) the cached would last from the Person to PersonDto conversion (including the nested Address to AddressDto). However, if the user explicitly asked to translate an Address to an AddressDto (not as part of a Person), then the cache would last just there...
It was therefore stored inside a ThreadLocal.

This allowed to convert complex structures such as graphs.

jandsu commented Jun 16, 2015

I had solved this in a former homegrown solution.
If this can help, what I ended up with was a cache:
[target class + source reference => target reference]
which I had implemented using:
HashMap<Class<TARGET>, HashMap<SRC, TARGET>>

The rationale for the target class was that the same "source" could be mapped twice in the DTO tree. The reason for not using an IdentityHashMap was that our underlying lib above JPA would possibly generate several instances for the same row in the database...

The cache only lived inside a top level conversion from the user... (it was cleared as soon as the conversion returned to the user). In other words, if I had a Person with an Address (both translating to PersonDto and AddressDto) the cached would last from the Person to PersonDto conversion (including the nested Address to AddressDto). However, if the user explicitly asked to translate an Address to an AddressDto (not as part of a Person), then the cache would last just there...
It was therefore stored inside a ThreadLocal.

This allowed to convert complex structures such as graphs.

julaudo pushed a commit to julaudo/selma that referenced this issue Mar 8, 2016

julaudo pushed a commit to julaudo/selma that referenced this issue Mar 8, 2016

julaudo pushed a commit to julaudo/selma that referenced this issue Mar 21, 2016

julaudo pushed a commit to julaudo/selma that referenced this issue Mar 21, 2016

@slemesle slemesle added this to the 0.15 milestone Mar 31, 2016

julaudo pushed a commit to julaudo/selma that referenced this issue Apr 19, 2016

julaudo pushed a commit to julaudo/selma that referenced this issue Apr 19, 2016

slemesle added a commit that referenced this issue Apr 19, 2016

slemesle added a commit that referenced this issue Jul 15, 2016

@slemesle slemesle closed this Jul 29, 2016

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