RE: [Hibernate] Hibernate and EMF integration

[Mike Kanaley]

Maybe straightforward for you J   Thanks for the note – at least I now know that we are not duplicating someone else’s effort.   Below are some of the basic issues encountered so far:   One of the main differences between POJOs and EMF EObjects is the way they deal with Collections. Say a Team class has a set of Players (cascade all) associated with it. In a POJO, you would have methods             Set getPlayers()             void setPlayers(Set) In an EObject, you would only have method             EList getPlayers()   1. Note that EMF owns the instantiation of the collection. An application (or Hibernate) cannot call setPlayers since it does not exist. The means we need to override the Hibernate’s BasicPropertyAccessor. Currently, I am making this a no-op since the list passed as the “value” into the Setter method:        void set(Object target, Object value, SessionFactoryImplementor factory) throws HibernateException; must have been allocated by the UserCollectionType implementation I supply below. Tell me if it is possible if this is not the case. Also, I am returning null from the Setter.getMethodName() and Setter.getMethod() methods too since the javadoc indicates that they are optional.   2. Note that the return type is an EList (which extends java.util.List). The EList implementations are special in the sense that they are aware of the model. For example, say you have team “Miami Heat” containing a player “Shaquille O'Neal” and suppose there is another team called “LA Lakers”. If Shaq is traded to the Lakers, you would have to call the following methods on the POJOs.             heat.remove(shaq)             lakers.add(shaq) However, with EMF, you simply have to call             lakers.add(shaq) The remove call will be handled by the EList implementation automatically – the collection implementation is “model-aware”.   This means we need to specify a UserCollectionType. Unfortunately, UserCollectionType’s instantiate method does not take the Serializable key that is available in CustomCollectionType’s init method. I need that key to be able to call the “EList getPlayers” method above to instantiate the collection that is model aware (EList implementations need to be aware of its owning object). Currently my UserCollectionType’s instantiate method looks like:     public PersistentCollection instantiate(SessionImplementor sessionImplementor, CollectionPersister collectionPersister, Serializable key) throws HibernateException {         EntityPersister persister = collectionPersister.getOwnerEntityPersister();         Object bean = sessionImplementor.getPersistenceContext().getCollectionOwner(key,collectionPersister);         return new PersistentList(sessionImplementor,                 (List)((BasicEntityPersister)persister).getClassMetadata().getPropertyValue(bean,collectionPersister.getNodeName(),sessionImplementor.getEntityMode()));     } This will likely change to set the PersistentList into the EMF delegating EList implementation so that EMF’s lazy loading chains into Hibernate’s lazy loading.   3. ELists are the only collection type, they represent Sets and Maps as well. I suspect Maps (which are ELists of key-value-pair objects) may pose a difficulty but I haven’t gotten to that yet.   Thanks so much for your time. -mike         From: Gavin King [mailto:[EMAIL PROTECTED] Sent: Saturday, June 04, 2005 11:59 AM To: Mike Kanaley; hibernate-devel@lists.sourceforge.net Subject: RE: [Hibernate] Hibernate and EMF integration   Hi Mike,   I’m not aware of any other effort to do this. It should be straightforward, however, given the architecture of HB3.   Gavin   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Kanaley Sent: Friday, 3 June 2005 9:35 PM To: hibernate-devel@lists.sourceforge.net Subject: [Hibernate] Hibernate and EMF integration   Unfortunately, there are integration problems when trying to persist Eclipse EMF objects with Hibernate.   A model architect uses an EMF class diagram (much like a UML class diagram) to model the data in the application. From this diagram, EObjects are generated. EObjects are EMF’s form of POJOs. EObjects are more complex than POJOs – they actually know about the model and support lazy loaded collections built into the generated objects.   Why not just use POJOs with Eclipse? Eclipse provides a framework on top of EMF that provides: -       XMI serialization -       Generated code based on EMF to support refactoring -       Cross-file reference resolution when serializing out a model to multiple files in a file system. -       Out of the box Eclipse editors for EMF objects (not that important since we are unlikely to ship these basic editors).   I won’t go into the details of integration issues in this email message. A short summary are: - UserCollectionType instances cannot be instantiated with knowledge of the “owning” instance. - EMF EObjects only support get methods for all collections. All collections are represented by an EList in EMF. - EMF’s lazy loading needs to delegate to Hibernate’s lazy loading   Small modifications to Hibernate are required to implement this support (as well as PropertyAccessor and UserCollectionType extensions).   TIBCO is not alone in this search as indicated in the thread below where someone has this working with JDO. http://www.jpox.org/servlet/forum/viewthread?thread=1802 However, TIBCO does not want to use a proprietary ORM library and we would rather use Hibernate than JDO. TIBCO wants to have an open source solution to this problem which is why we are approaching you.   Are you aware of others trying to integrate Hibernate and EMF? TIBCO will provide the implementation resources but would like a Hibernate team liaison to review the design with a long term goal of having Hibernate support this functionality.   Thanks for your time, Michael Kanaley Principal Architect TIBCO Software Inc.