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

[Joerg von Frantzius <joerg.von.frantzius@xxxxxxxxxxxxxxxxxxxx>]

Hi Mike,

first of all thanks for making an end to my speculations on what was going on in the expert group ;)

Mike Keith schrieb:

Joerg,

The subject of fetch groups did in fact come up in the EJB 3 expert group, and we (Oracle) along with others including JBoss, BEA and IBM concluded that fetch groups sound better in theory than they are in practice. In practice, fetch groups are much like lazy loading of attributes in that very rarely do they ever really result in better performance. The two cases where they can do are

Maybe that's a misunderstanding, as JDO fetch-groups can be used both for eager-fetching and lazy-loading. While in EJB3 you would use a JOIN query on the association fields to be eager-fetched, in JDO2 you would just put them in a fetch-group. That puts control over fetching into a single conceptual place, so that you can easily distinguish fetch-behaviour for different use-cases in the metadata. It doesn't disperse that information on metadata, code and queries as in EJB3 currently.

when there is a large number of columns in a table mapped to one object or when there is a single attribute that is very large (e.g. a LOB). All other cases will normally end up causing worse performance, not better.

Maybe that conclusion is due to the same possible misunderstanding that fetch groups would only declare lazy loading.

The solution to the first case is to use an embedded object, while the second can be lazily loaded at the attribute level.

To be clear, they were NOT rejected because we do not support fetch groups -- because we do in TopLink and I believe that Hibernate does as well, although I am not sure about IBM and BEA -- but

I don't know what TopLink has there, but Hibernate had introduced something they call themselves a "marketing feature", the purpose of which seems only to be that they can claim support for "fetch groups"; they openly say somewhere else that this is a marketing checkbox feature. However, this "lazy property fetching" is only for lazy fetching and it can be declared only once for a class on field level, effectively making up for only one (lazy) fetch group per class definition.

This is in contrast to the concept of JDO2 fetch groups, which allow for an arbitrary number of fetch groups (sets of fields to be fetched) declared per class, e.g. for different use-cases. These groups can then be dynamically chosen and combined at runtime, together with the predefined groups ALL and EMPTY or the default fetch group.

I'd say Hibernate does not support fetch groups, but a half-hearted attempt to fake it.

because they are prone to misuse and a complication that we did not feel was warranted in the specification.

What misuse could that be? What complication do they add other than for the ORM implementation?

Hope this clears things up a little.

Thanks, it did!

Regards,
Jörg