Thanks for the tip on PersistentCollection.setOwner. That will likely work.
As for "EMF persistence", let me try to explain how I think it differs from Hibernate (including XML support). I view Hibernate's XML support as serialization and not persistence. IMO Eclipse's raison d'tre is to provide an IDE platform. Eclipse-based IDEs have some special characteristics to them. Eclipse's notion of persistence revolves around a "ResourceSet". You can think of a ResourceSet as a set of files in a single directory in the filesystem. It is roughly equivalent to a Hibernate Session but has many different characteristics (like no query other than by path). First and foremost, when objects are stored, they are given a "location" (aka URI) in the ResourceSet (think a path to a file). This allows easy integration with a source control system. In fact, this "location" is the "primary key" of the object (but it is not stored in the object). ResourceSets typically live as long as an editor is open (as compared to a Session that is connected to a JDBC connection for short periods only). Notifications can setup on Resources (think files) so if the file is changed outside of editor/ResourceSet, the editor can receive a notification of the change (see the following example). For example, say a Team class has properties name, city and a set of Players (non-containment) in the "team" EMF package. Say a Player has property name. Using EMF, you would create a ResourceSet that is associated with some directory. Create a player instance with name "Shaq". Then create a team instance with name "Heat", city "Miami" and add "Shaq" to the set of Players using team.getPlayers().add(shaq). Then you associate the team with URI "/teams/heat.team" and the player with "/players/Shaq.team". Note that the file extension is the same - this is because both classes are in the "team" EMF package. If you look inside heat.team then you will see a reference in the XMI to shaq using the URI "/players/Shaq.team". We term this a "cross-file" reference. In IDEs, you need to be able to "refactor" Shaq.team and move it to another location. This in turn will cause notifications to resource sets so their references can be updated. Sometime refactoring requires changing both the location and the name inside of the object. This is annoying but necessary - consider a java class where the package name or class name does not match that of the path to the .java file. The location is readable (set by a developer/designer) as compared to generated (there is no generated property value support in EMF that I know about). In fact, I could imagine that many EMF objects that when mapped to a RDBMS with Hibernate, will add a generated primary key property that is not in EMF class to replace the "location based references" that don't make sense in an RDBMS. Part of this EMF->Hibernate integration also requires extending the EMF platform so instead of resolving "location based references" actually calls the Hibernate lazy loading collection instead. BTW, EMF is relatively disjoint from Eclipse. It requires the following plugins: org.eclipse.emf.common org.eclipse.emf.ecore org.eclipse.emf.ecore.xmi This is 5 jars files (2 resource bundle jars are needed) for a total of about 700K. -mike > -----Original Message----- > From: baliuka juozas [mailto:[EMAIL PROTECTED] > Sent: Monday, June 06, 2005 2:44 AM > To: Max Rydahl Andersen; Mike Kanaley; Gavin King; hibernate- > [EMAIL PROTECTED] > Subject: Re: [Hibernate] Hibernate and EMF integration > > > This is one of examples ("containment" with "opposite" > association), but generated code depends on model too, > "reference" will be generated in different way and you > need to know model to persist it in the right way > (generated code has meta information). It is not a > good idea to asume generated code implementation, it > must be better to see EMF reflection related stuff > (EObject methods with "e" prefix) and > standard EMF way to integrate custom persistence is > "Resource" API > > --- Max Rydahl Andersen <[EMAIL PROTECTED]> > wrote: > > > > > And this code is auto-generated into your "domain" > > classes ? > > Damn - EMF is way more intrusive than I thought. > > > > But anyhow - "elements" is some field, right ? Then > > hibernate can set it! > > > > Regarding getting the "owning element" into the > > collection. > > Can only tell that PersistentCollection.setOwner() > > will be called > > immediatly after instantiation - > > is that not enough for you ? > > > > I would expect you would not need to actually > > instantiate the underlying > > collection before you are actualled accessed. > > > > /max > > > > > > > > > > It looks something like this: > > > > > > public EList getElements() { > > > if (elements == null) { > > > elements = new > > > > > EObjectContainmentWithInverseEList(MyElement.class, > > > this, MyGenPackage.ELEMENTS_FEATURE_ID, > > > MyGenPackage.PARENT_FEATURE_ID); > > > } > > > return elements; > > > } > > > > > > This stuff depends on EMF interfaces and > > > implementation classes, probably code generation > > > "pattern" depends on EMF versions too. > > > Common EMF use case are generated "metamodel" (it > > is > > > used by modeling tools like UML diagram editors) > > > custom code is generated from "metamodel" using > > custom > > > templates and "patterns" without EMF dependecy . > > > > > > --- Max Rydahl Andersen <[EMAIL PROTECTED]> > > > wrote: > > > > > >> > 1. Note that EMF owns the instantiation of the > > >> collection. > > >> > > > >> > An application (or Hibernate) cannot call > > >> setPlayers since it does not > > >> > exist. > > >> > > >> so how does EMF set it ? > > >> > > >> /max > > >> > > >> > > >> > > > > > > ------------------------------------------------------- > > >> This SF.Net email is sponsored by: NEC IT Guy > > Games. > > >> How far can you shotput > > >> a projector? How fast can you ride your desk > > chair > > >> down the office luge track? > > >> If you want to score the big prize, get to know > > the > > >> little guy. > > >> Play to win an NEC 61" plasma display: > > >> http://www.necitguy.com/?r=20 > > >> _______________________________________________ > > >> hibernate-devel mailing list > > >> hibernate-devel@lists.sourceforge.net > > >> > > > > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > >> > > > > > > > > > > > > > > > __________________________________ > > > Do you Yahoo!? > > > Yahoo! Mail - Find what you need with new enhanced > > search. > > > http://info.mail.yahoo.com/mail_250 > > > > > > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. > > How far can you shotput > > a projector? How fast can you ride your desk chair > > down the office luge track? > > If you want to score the big prize, get to know the > > little guy. > > Play to win an NEC 61" plasma display: > > http://www.necitguy.com/?r=20 > > _______________________________________________ > > hibernate-devel mailing list > > hibernate-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel
