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

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

Max Rydahl Andersen schrieb:

I can't see how retrieving the ids could be of help here, as that  doesn't give
you "hollow" objects as in JDO, which you can use as a table input with  their
field values being lazy-loaded initially for the first k visible rows of  the
table.

There are many ways to skin a cat. I will claim I can solve the exact same
problem (preloading a table as quickly as possible) without requiring  shallow
objects (if I had a large list I would not load the shallow objects).

Its two different ways of solving it - and both have  advantages/disadvantages.
Claiming one is more right for RCP applications because of this is wrong  IMO.

Max, the point is not only about preloading it as quickly as possible, but also that the user must not need to wait before it is done. Using EJB3, I could imagine using shallow objects (all fields declared to lazy-load) to have at least that, but then I still don't see how you can do the full load in O(k) SELECT statements without something really horrible like having two class definitions, one with lazy-loaded fields and one without, for fast loading.

Basically, you still left the question unanswered: how do you do it in O(k) instead of O(n)? Just claiming that you can do it somehow isn't very convincing.

For the sake of the best thinkable technology becoming a Java standard, why don't you just say alright, EJB3 is missing something here. I mean who said EJB3 is perfect, or JDO2? Why not be open to putting it on the agenda for EJB 3.1 or something, or to making it an optional feature? If you say nobody needs fetch-groups, then you shouldn't mind competing implementors featuring it, but they should be able to feature it as per the standard.

I can't help it, but to me this seems to be a constant denial of facts, somehow reminding me of Microsoft's usual stance. It makes me furious that this short-sighted over-protection of interests seems to be a major influence on the EJB3 expert group, potentially putting Java on the client side at danger. Java's competition here is Microsoft, and you're actively sabotaging Java's competitiveness here.