The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

expp (2) [Avatar] Offline
#1
Hello
thanks for your previous answer

Let's look at the common problem:

Guideline says do not customize fetching and eager loading in the entity mapping, and optimize fetching with 'fetch join' queries (or use second layer cache).
Ok. its good but how to implement that? fetch queries was putted to Repository or Result Factory, but if second layer cache is introduced we have to remove them!!!. Named queries in xml do not solve this problem: "if you change fetching or caching policy you have to fix your source". I think that all pojo fans needs in the followed thing:

"It is a fetching service which is called from all application's facades. Facade passes to it entity collection (which may be proxies) and the 'use case identificatior' (string) which is a fetch group. Fetching service reads fetch group from xml and fetch entities in the passed collection. Main advantages is remove fetching logic from code and the possibility to change it in the deployment time (same as you change caching policy)"

second feature is initializing entities for detaching. Also we can bind this service to facades by annotating it!!!
first scratches:

interface FetchingService{
void fetchCollectionOf(Collection proxies, Class forFetch, String fetchGroup);
void initializeCollectionOf(Collection proxies, Class forFetch, String fetchGroup)
}

xxx-fetch.xml
<class name="TheEntity">
<fecth-group name="list.use.case">
<to one="assoc1"/>
<to one="assoc2">
<to many="subassoc"/>
</to>
<to many="collection1">
</fecth-group>
</class>

what you think about this?