| Change Collection Mapping Selection Criteria on the fly [message #1776423] |
Thu, 16 November 2017 05:58  |
Eclipse User |
|
|
|
Hi everyone,
I have a problem, the question is we have multiple nested entities with unidirecitonal mapping through out the platform. Because of which any criteria applied to the parent entity fetches all the children.
Let's say A has a one to many to B. If I query for A with criteria where A.B.id = 10, it will fetch that A but it will fetch all the B's in it. The behavior I'm looking for is fetch that A but fetch only that B which it was queried for.
I know this is the default behavior, I have read a lot on partial output. I have tried with some success to even achieve it by changing the selection criteria of the collection mapping in the class descriptor and could successfully get the behavior. But the problem is that the class descriptor seems to carry that selection criteria for the subsequent queries and reset only when the descriptors are loaded at deployment. Meaning restart the web container.
This is really killing us because it is fetching unnecessary children which takes up unnecessary network bandwidth. I know the standard approach is have a bidirectional mapping. But understand that, it comes with it's own nuances of cyclic dependencies and we have about 700+ entities and overnight we cannot change this approach, maybe a year or so but not now.
So I would please ask you guys if there was any way to set the selection criteria for collection mapping before preparing the query and reset it back after executing the read all query, I would be grateful. I have tried it before getting the entity manager and also in the descriptoreventlisener but I haven't been able to figure out what is the post execution in the lifecycle of query execution. And if so, how could I reset it?
|
|
|
| Re: Change Collection Mapping Selection Criteria on the fly [message #1776798 is a reply to message #1776423] |
Tue, 21 November 2017 12:59  |
| Eclipse User |
|
|
|
Using "a.b.id =10" does not cause any Bs to be fetched - this is entirely controlled through the mapping and 'fetch' qualifiers or hints added to the query. Unfortunately, what you are looking for seems to be a way to manipulate how entities are built based on the criteria selection, rather than just what is returned. Your query will return associated As, but has no way of controlling the references from A, and is beyond JPA - JPA requires entities to match what is in the database, as providers need a way to be able to handle changes.
What you might try instead is returning the Bs or other associated entities and work backward to the A. in the example, you could either select for B, or return A and Bs, and use these results rather than traverse the A->B reference:
"Select a, b from A a join a.b b where b.id = 10"
EclipseLink does allow filtering on the mapping, but this isn't dynamic - it is meant for implementing things like soft deletes.
|
|
|
| Re: Change Collection Mapping Selection Criteria on the fly [message #1776803 is a reply to message #1776798] |
Tue, 21 November 2017 13:53 |
| Eclipse User |
|
|
|
|
I was so not hoping for this response. But thanks anyway Chris, you're right in saying query for B and work backwards to A, since we are accessing these entities through REST services and as I mentioned we have a lot of entities already written, so what you basically said is have a bidirectional relationship and have services exposed to B which have a 1:1 relationship with A. Unfortunately it requires a heavy change and I was looking for a solution if it exists with the present scenario.
|
|
|
Powered by
FUDForum. Page generated in 0.03665 seconds
Home