Patrick - I pulled an OpenJPA 1.1.0-SNAPSHOT from SVN and built it locally to give it a whirl - and indeed this appears to work like a charm! Great.
Can anybody provide insight on about what timeframe your hoping to push v1.1 to a release? Roughly. PS: I'm using the following annotations: @PersistentCollection(elementEmbedded=true) @ContainerTable(name="RelA___RelB", [EMAIL PROTECTED](name="A_ID")) private Set<RelB> bs = new HashSet<RelB>(); Thanks! -----Original Message----- From: Patrick Linskey [mailto:[EMAIL PROTECTED] Sent: jeudi, 20. mars 2008 17:55 To: [email protected] Subject: Re: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ? Hi, You're describing the use case for the @Embeddable annotation in JPA. You're also describing a feature that's there in OpenJPA 1.1.0-SNAPSHOT but not in OpenJPA 1.0 -- embedded values in collections. Upgrade and things should work. FWIW, this behavior will be part of JPA2. -Patrick On Mon, Mar 17, 2008 at 11:07 AM, Michael Vorburger <[EMAIL PROTECTED]> wrote: > Hi, > > I need to map the Elements contained in a OneToMany Collection (Set) > in some class to one table, and Elements of the same Class Type > contained in a OneToMany Collection (Set) in another class to another > table. Know what I mean? > > The example on the Subscription/LineItem example from > http://openjpa.apache.org/builds/1.0.2/apache-openjpa-1.0.2/docs/manua > l/ manual.html#ref_guide_mapping_jpa_onemany works (of course), but > imagine another class that holds the same kind of LineItem classes.. > another @OneToMany @ElementJoinColumn will lead to another inverse > foreign key mapping, and the one and only SUB table will have two; > not what I want. > > Now before somebody says RTFM ;) - I read about the > @PersistentCollection(elementEmbedded=true) @ContainerTable (in the > OpenJPA doc just above the link above, but the example on > http://edocs.bea.com/kodo/docs41/full/html/ref_guide_mapping_ejb.html# > re f_guide_mapping_ejb_coll_ex helped) and it indeed does the mapping > as I'm expecting it... but also adds a weired unneccassyary > additional column of type 'image' (on Sybase, a BLOB on Derby) named > after the Collection field (e.g. items) - on the LINE_ITEM instead of > on the SUB table! How do I get rid of that column? > > I noticed Kodo has an @ElementEmbeddedMapping that's not in OpenJPA, > but from what I understand that's only to override stuff? That > @PersistentCollection(elementEmbedded=true) already says the Elements > should be embedded. So why that additional binary column? Or this kind > of mapping impossible with OpenJPA (it's clearly possible - there is > just an additional annoying column...) Is there a way to do the same > differently? > > BTW: I'm assuming somebody who would for some reason have two > collections of LineItem in the Subscription class (instead of from two > different classes) would probably have a very similar mapping > requirement. > > Thanks! > Michael > > ____________________________________________________________ > > * This email and any files transmitted with it are CONFIDENTIAL and intended > solely for the use of the individual or entity to which they are addressed. > * Any unauthorized copying, disclosure, or distribution of the material within > this email is strictly forbidden. > * Any views or opinions presented within this e-mail are solely those of the > author and do not necessarily represent those of Odyssey Financial > Technologies SA unless otherwise specifically stated. > * An electronic message is not binding on its sender. Any message referring to > a binding engagement must be confirmed in writing and duly signed. > * If you have received this email in error, please notify the sender immediately > and delete the original. > -- Patrick Linskey 202 669 5907 ____________________________________________________________ This email and any files transmitted with it are CONFIDENTIAL and intended solely for the use of the individual or entity to which they are addressed. Any unauthorized copying, disclosure, or distribution of the material within this email is strictly forbidden. Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of Odyssey Financial Technologies SA unless otherwise specifically stated. An electronic message is not binding on its sender. Any message referring to a binding engagement must be confirmed in writing and duly signed. If you have received this email in error, please notify the sender immediately and delete the original.
