[news.eclipse.technology.ejb-orm] Re: correction: EJB3 is specified for

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

> The two I know is JBoss/Hibernate EntityManager  
> (entitymanager.hibernate.org)
> and Oracle (http://www.oracle.com/technology/ejb3/index.html).
> Others here can probably list more (I saw Robert mention 2 more)
> Alright. I'm surprised ;-)
> Especially seeing Oracle already supporting "out-of-container" usage

well, one learn every day ;)

> that makes use of it? For JDO 2.0, I know at least of one in production  
> use. We
> created that one using JPOX, though, not VOA.
> Do you know of any RCP application, or some other client application  
> with a GUI,
>
> No, I don't know of any RCP application using EJB3 nor JDO2 (before the  
> one you
> just mentioned).
> But I know of a couple that uses Hibernate with Eclipse RCP and they  
> should have
> no apparent problems using it (but that of course is not what you asked  
> for ;)
> RCP on Hibernate is still news to me! I had to make use of JDO  
> fetch-groups to
> get things perfomant enough when e.g. displaying large tables, and I  
> believed
> Hibernate eager-fetching support too unflexible for this.

Have no idea why querying isn't sufficient for you since you here can very
precisly specify what part of your object graph you want to load.

(but I guess you prefer implicit dataloading via object graph navigation  
instead of explicit data querying ?)

> Fetch-groups also
> allowed me to lazy-load large BLOB columns, something that Hibernate in  
> it's
> documentation calls "a checkbox feature that Hibernate needs for  
> marketing
> purposes", although it is feature that was absolutely essential to me.  
> It is
> things like that which cause my doubts on Hibernate, and EJB3 in  
> consequence.

Well we have it, but does not encourage it - I never understood why
being honest about performance and poor-design is a bad thing ;)

(and it can be done in other ways)

> For anyone else interested, here is a little list of explicit Hibernate
> restrictions (sorry, couldn't resist to post this ;)

Again, a very bad google search since all of these restrictions are just
documented restrictions - all of them very natural limitations which
you probably will also find in other JDO or EJB3 implementations.

So, just to be "fair" i'll do the same for jpox:
http://www.google.com/search?hl=en&lr=&q=%22jpox+does+not+support%22+site%3Awww.jpox.org&btnG=Search

interesting, eh ? 10 hits in hibernate vs 44 jpox :) (please notice my  
smiley here! Those two searches are totally irrelevant)

Again - it seems being honest about what is doable and what is not doable  
(in
a good way) via ORM/EJB3/Hibernate is a bad thing ?!

> using EMF to describe the model, but the implementation classes do not  
> extend
> EObjectImpl (though they still implement the interfaces, of course).  
> Elver makes
> use of EObjectImpl.

This is one of the intrusive design issues I don't like.

> EMF has some very intrusive design issues that makes it very hard to  
> persist and
> query completely and efficiently -
> would be interested in hearing how much they have solved of that.
> What exactly are these design issues? E.g. Bidirectional integrity?

Required to implement specific interfaces
non-standard Collections

and more - but i'll have to write this down someday so people can tell me
back how to workaround it or give a good reason ;)

/max