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

["Max Rydahl Andersen" <max.andersen@xxxxxxxxx>]

> 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

> As far as I can see, what is doable with EJB3 will take you O(n) SELECT
> statements (n being the number of objects), in contrast to O(k) SELECT
> statements with JDO (k being a small constant). That's one real hell of a
> difference! That's the number of SELECTs until the table contents are  
> fully
> loaded into memory, with the first rows being visible before it is fully  
> loaded,
> and the user at least being able to scroll with perceivable delays  
> before it is
> fully loaded, and with no perceivable delays once it is loaded.
>
> If that can be done with EJB3 in O(k), then please tell me how exactly  
> that can
> be done. Until then, I'd say EJB3 is badly missing the concept of  
> fetch-groups.
> Maybe someone else of the JSR220 experts assembled here has an idea how  
> it can
> be done in O(k) with EJB3?
>
> My insisting here might seem a bit trollish, but things like that  
> absolutely
> make a difference for RCP fat clients. The technical competitor here is  
> MS
> Access, and that has some really damn fast table loading.



--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/