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

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

Mike Keith schrieb:

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.

But it doesn't work for simple fields. Let's assume we have declared some simple fields of a class to be fetched lazily. FETCH JOIN won't help you then to prevent extra SELECT statements for these fields, as FETCH JOIN only applies to association paths. Even if my use-case is what you call rare, it would make me uncomfortable to know that once a simple field is being annotated as lazy, it will *always* be fetched lazy. Or is there some other way to override lazy annotation of simple fields, except for scalar queries (see below)?

If e.g. I have a class with 10 simple attributes, out of which 5 are shown in the GUI table and all 10 in a details view, then I can optimize for the GUI table using lazy annotations, but not for the details view. That will give you 4 needless select statements for the details view, which can be noticeable when network latency isn't the best.

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).

Scalar queries are basically the same as using JDBC ResultSets: what's the difference between working with an untyped Object[] and a ResultSet? I'd regard it a conceptual defeat of an ORM layer if the programmer must resort to something like this, unless in the specification object-orientedness and type-safety in particular are regarded of low importance.

I mean that's what an ORM layer is for after all: that the details of relational persistence are hidden from me as an object oriented programmer. As the latter, I don't find it comfortable either that I need to know about JOIN FETCHes. It would increase the average Java programmers productivity if he doesn't need to learn about these before being able to effectively use an ORM tool, as with JOIN FETCH he not only needs to know what he wants to have fetched, but also how. Is transparency of relational persistence an ideal for EJB3 or not?

Again on the question of where lazy/eager is defined: if you have lazy annotations for association fields for use-case a, and you need to fetch them eagerly in use-case b, you will have the definition of fetch behaviour spread over both meta-data and query definitions in the source code, or you might even have to construct queries in your source code. Maybe it's a matter of taste, but I'd think it would be better to have it in one place. If you have a handful of use cases, I'd expect this to become really ugly.