FetchEager for ManyValuedAssociations

BIZ TMS Aurelius
1

Out of:
https://doc.tmssoftware.com/biz/aurelius/guide/queries.html#specifying-eager-fetching-for-associations-loaded-as-lazy-by-default

Did I get it right, that FetchEager is only working correctly for Associations and not for ManyValuedAssociations?

Find<TEnity>.FetchEager('Entity2List').RemovingDuplicatedEntities.List;

Generates this statement:

Select ...
  from Entity a
  left join Entity2 b on (a.id = b.Entity_ID);

But property Entity.Entity2List is not Loaded, so accessing proxy-value will fire

Select ...
   from Entity2
  where Entity_ID = :p_0

Is there any possibility fetching ManyValuedAssociations to it's corresponding list in a single statement?

2

Well, I would say you get it right that FetchEager only causes a single SQL statement to be executed for associations and not for many-valued associations.

But both are working "correctly". Eager fetching means all associations (single and many-valued) will be loaded at the time the parent object is retrieved.

But many-valued fetching is not optimized to be in a single statement. They will still fire one SQL statement for each list.

3

Will these Statemens be optimized in future?

4

There is no current plans to do so, as this is not even possible in all scenarios. For example, if an entity has two different lists. The workaround is to query the entities from the detail part, and then eager fetch the parent objects.

5

concerning your changelog of october:

  • Improved: Select projections and fetch eager information now work for many-valued associations. This allows you to improve performance when retrieving lists (many-valued associations), by selecting a subset of the properties to be returned.

means, this is implemented now?

6

Not exactly. Two things have been implemented:

  1. FetchEager now applies to many-valued association, meaning that the SQL to retrieve the list will be executed right away, instead of delayed until the list property is read from the class. But still, one SQL statement is executed for each list.

  2. With 1 implemented, it's now possible to use selected projections to choose the properties that will be retrieved for the list items.

7

But accessing lists after they were filled with FetchEager will not trigger additional Requests later on, as my tests are showing.

Yes, there are several SQLs triggered, but before your changes of october, accessing list properties, that should have been fetched by FetchEager triggered these List-Statements again, so that these were fired several times, because Proxy.Loaded was false

8

That's exactly what I said in item 1.

I'm not sure what is your point?