[news.eclipse.technology.ejb-orm] Re: JDO fetch-groups important for RCP

[michael.keith@xxxxxxxxxx (Mike Keith)]

Joerg von Frantzius wrote:

> > Note that in EJB 3 the eager/lazy loading is defined in the mappings, 
> > not in the EJB QL. Lazy fetching of a relationship may be triggered, 
> > though, by using a FETCH JOIN in an EJB QL statement. Simple JOIN 
> > statements just call out the semantics of what is happening when

> Did you mean "/Eager/ fetching of a relationship may be triggered..."? 
> Spec says in 4.4.5.3:

Yes, another way of saying the same thing. Prefetching, or triggering a 
relationship that has been defined to be lazy fetched.

> I really haven't seen that EAGER can be annotated as well, though, so I 
> was wrong, that's really in the metadata as well. Do you know whether 
> EAGER and LAZY can be dynamically turned off at runtime? I haven't seen 
> any mention of that in "9.1.15 Basic Annotation", where the annotation 
> is defined.

Lazy/eager fetching in the spec is currently defined in static metadata. 
If there is any need to trigger a lazily loaded relationship then it may 
be done at runtime using FETCH JOIN described above.

> In the rare case that the user now clicks through the whole table, 
> looking at all attributes in all possible views, then he might indeed 
> have in the end accumulated all values of all attributes in memory. 
> /But/ he got to see everything as quickly as possible on every click of 
> a button or selection of a GUI table row, and that's what counts here. I 
> don't care much if in a GUI application the overall number of select 
> statements over time is "suboptimal", if response time is optimal. In 
> fact response time would be absolutely compromised by trying to optimize 
> the overall number of select statements.

Fetch groups are not necessary for a GUI view. Lazy loading suffices. 
Multiple different GUI views over the same object is not a common or 
compelling enough use case IMO to warrant introduction of fetch groups, 
given that there are other ways of accomplishing this (one of which is to 
use scalar data).

-Mike