You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@openjpa.apache.org by Michael Vorburger <mv...@odyssey-group.com> on 2008/03/17 19:07:39 UTC
One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
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/manual/
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.
Re: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Kevin Sutter <kw...@gmail.com>.
Michael,
You are correct. We are planning for the support of embedded collections in
JPA 2.0. There is an Early Draft Review of the spec available for public
reviewal (http://jcp.org/aboutJava/communityprocess/edr/jsr317/index.html).
It would be great if you could review the appropriate sections of this spec
and see if the expert group is defining the support you are looking for.
The referenced page outlines how you can provide feedback directly to the
expert group.
Thanks,
Kevin
On Wed, May 7, 2008 at 10:27 AM, Michael Vorburger <
mvorburger@odyssey-group.com> wrote:
> Hello, my last phrase "are there any plans" was actually a question, no
> response... really no comment? This is unfortunately turning into a
> show stopper for our use of OpenJPA, and we probably have to have a look
> at another ORM ;-( which seems to support this kind of mapping... whine
> whine, hope hope for a magic answer that this is just coming... ;-)
>
> PS: I looked through the JIRA and couldn't see anything related to this,
> so I took the liberty to file
> https://issues.apache.org/jira/browse/OPENJPA-593, hope that's OK.
>
>
> -----Original Message-----
> From: Michael Vorburger
> Sent: mercredi, 30. avril 2008 00:48
> To: users@openjpa.apache.org; dev@openjpa.apache.org
> Subject: RE: One-Sided One-Many Mapping, but to different tables -
> missing @ElementEmbeddedMapping ?
>
> PS: I just saw that http://jcp.org/en/jsr/detail?id=317 (Java
> Persistence 2.0) says "... support for collections of embedded objects,
> multiple levels of embedded objects ..." ... hm.
>
> Can anybody comment if there are plans for this?
>
>
> -----Original Message-----
> From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
> Sent: Tue 4/29/2008 7:48 PM
> To: users@openjpa.apache.org
> Subject: RE: One-Sided One-Many Mapping, but to different tables -
> missing @ElementEmbeddedMapping ?
>
> Hello again,
>
> Actually, this doesn't work as expected for us after all... limitation:
>
> <openjpa-1.1.0-SNAPSHOT-r422266:641891M fatal user error>
> org.apache.openjpa.util.MetaDataException: "X.y<element:class Y>" is
> mapped as embedded, but embedded field "..." is not embeddable.
> Embedded element/key/value types are limited to simple fields and direct
> relations to other persistent types.
>
> The message is clear in what it means, but this actually limits the
> usefulness of this somewhat. (A colleague tells me in Hibernate this
> kind of mapping is possible.)
>
> I don't suppose there are any plans to address this limitation (or later
> version already have; I'm on a 1.1.0-SNAPSHOT.jar built from trunk as of
> 29.03.2008).
>
> Regards,
> Michael
>
>
> -----Original Message-----
> From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
> Sent: samedi, 29. mars 2008 03:14
> To: users@openjpa.apache.org
> Subject: RE: One-Sided One-Many Mapping, but to different tables -
> missing @ElementEmbeddedMapping ?
>
> 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",
> joinColumns=@XJoinColumn(name="A_ID"))
> private Set<RelB> bs = new HashSet<RelB>();
>
> Thanks!
>
>
> -----Original Message-----
> From: Patrick Linskey [mailto:plinskey@gmail.com]
> Sent: jeudi, 20. mars 2008 17:55
> To: users@openjpa.apache.org
> 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
> <mv...@odyssey-group.com> 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.
>
> ____________________________________________________________
>
> . 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.
>
>
>
>
>
>
>
> ____________________________________________________________
>
> • 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.
>
RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Michael Vorburger <mv...@odyssey-group.com>.
Hello, my last phrase "are there any plans" was actually a question, no
response... really no comment? This is unfortunately turning into a
show stopper for our use of OpenJPA, and we probably have to have a look
at another ORM ;-( which seems to support this kind of mapping... whine
whine, hope hope for a magic answer that this is just coming... ;-)
PS: I looked through the JIRA and couldn't see anything related to this,
so I took the liberty to file
https://issues.apache.org/jira/browse/OPENJPA-593, hope that's OK.
-----Original Message-----
From: Michael Vorburger
Sent: mercredi, 30. avril 2008 00:48
To: users@openjpa.apache.org; dev@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
PS: I just saw that http://jcp.org/en/jsr/detail?id=317 (Java
Persistence 2.0) says "... support for collections of embedded objects,
multiple levels of embedded objects ..." ... hm.
Can anybody comment if there are plans for this?
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: Tue 4/29/2008 7:48 PM
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
Hello again,
Actually, this doesn't work as expected for us after all... limitation:
<openjpa-1.1.0-SNAPSHOT-r422266:641891M fatal user error>
org.apache.openjpa.util.MetaDataException: "X.y<element:class Y>" is
mapped as embedded, but embedded field "..." is not embeddable.
Embedded element/key/value types are limited to simple fields and direct
relations to other persistent types.
The message is clear in what it means, but this actually limits the
usefulness of this somewhat. (A colleague tells me in Hibernate this
kind of mapping is possible.)
I don't suppose there are any plans to address this limitation (or later
version already have; I'm on a 1.1.0-SNAPSHOT.jar built from trunk as of
29.03.2008).
Regards,
Michael
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: samedi, 29. mars 2008 03:14
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
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",
joinColumns=@XJoinColumn(name="A_ID"))
private Set<RelB> bs = new HashSet<RelB>();
Thanks!
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: jeudi, 20. mars 2008 17:55
To: users@openjpa.apache.org
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
<mv...@odyssey-group.com> 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.
____________________________________________________________
. 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.
____________________________________________________________
� 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.
RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Michael Vorburger <mv...@odyssey-group.com>.
Hello, my last phrase "are there any plans" was actually a question, no
response... really no comment? This is unfortunately turning into a
show stopper for our use of OpenJPA, and we probably have to have a look
at another ORM ;-( which seems to support this kind of mapping... whine
whine, hope hope for a magic answer that this is just coming... ;-)
PS: I looked through the JIRA and couldn't see anything related to this,
so I took the liberty to file
https://issues.apache.org/jira/browse/OPENJPA-593, hope that's OK.
-----Original Message-----
From: Michael Vorburger
Sent: mercredi, 30. avril 2008 00:48
To: users@openjpa.apache.org; dev@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
PS: I just saw that http://jcp.org/en/jsr/detail?id=317 (Java
Persistence 2.0) says "... support for collections of embedded objects,
multiple levels of embedded objects ..." ... hm.
Can anybody comment if there are plans for this?
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: Tue 4/29/2008 7:48 PM
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
Hello again,
Actually, this doesn't work as expected for us after all... limitation:
<openjpa-1.1.0-SNAPSHOT-r422266:641891M fatal user error>
org.apache.openjpa.util.MetaDataException: "X.y<element:class Y>" is
mapped as embedded, but embedded field "..." is not embeddable.
Embedded element/key/value types are limited to simple fields and direct
relations to other persistent types.
The message is clear in what it means, but this actually limits the
usefulness of this somewhat. (A colleague tells me in Hibernate this
kind of mapping is possible.)
I don't suppose there are any plans to address this limitation (or later
version already have; I'm on a 1.1.0-SNAPSHOT.jar built from trunk as of
29.03.2008).
Regards,
Michael
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: samedi, 29. mars 2008 03:14
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
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",
joinColumns=@XJoinColumn(name="A_ID"))
private Set<RelB> bs = new HashSet<RelB>();
Thanks!
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: jeudi, 20. mars 2008 17:55
To: users@openjpa.apache.org
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
<mv...@odyssey-group.com> 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.
____________________________________________________________
. 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.
____________________________________________________________
� 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.
RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Michael Vorburger <mv...@odyssey-group.com>.
PS: I just saw that http://jcp.org/en/jsr/detail?id=317 (Java Persistence 2.0) says "... support for collections of embedded objects, multiple levels of embedded objects ..." ... hm.
Can anybody comment if there are plans for this?
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: Tue 4/29/2008 7:48 PM
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Hello again,
Actually, this doesn't work as expected for us after all... limitation:
<openjpa-1.1.0-SNAPSHOT-r422266:641891M fatal user error>
org.apache.openjpa.util.MetaDataException: "X.y<element:class Y>" is
mapped as embedded, but embedded field "..." is not embeddable.
Embedded element/key/value types are limited to simple fields and direct
relations to other persistent types.
The message is clear in what it means, but this actually limits the
usefulness of this somewhat. (A colleague tells me in Hibernate this
kind of mapping is possible.)
I don't suppose there are any plans to address this limitation (or later
version already have; I'm on a 1.1.0-SNAPSHOT.jar built from trunk as of
29.03.2008).
Regards,
Michael
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: samedi, 29. mars 2008 03:14
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
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",
joinColumns=@XJoinColumn(name="A_ID"))
private Set<RelB> bs = new HashSet<RelB>();
Thanks!
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: jeudi, 20. mars 2008 17:55
To: users@openjpa.apache.org
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
<mv...@odyssey-group.com> 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.
____________________________________________________________
. 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.
____________________________________________________________
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.
RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Michael Vorburger <mv...@odyssey-group.com>.
PS: I just saw that http://jcp.org/en/jsr/detail?id=317 (Java Persistence 2.0) says "... support for collections of embedded objects, multiple levels of embedded objects ..." ... hm.
Can anybody comment if there are plans for this?
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: Tue 4/29/2008 7:48 PM
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Hello again,
Actually, this doesn't work as expected for us after all... limitation:
<openjpa-1.1.0-SNAPSHOT-r422266:641891M fatal user error>
org.apache.openjpa.util.MetaDataException: "X.y<element:class Y>" is
mapped as embedded, but embedded field "..." is not embeddable.
Embedded element/key/value types are limited to simple fields and direct
relations to other persistent types.
The message is clear in what it means, but this actually limits the
usefulness of this somewhat. (A colleague tells me in Hibernate this
kind of mapping is possible.)
I don't suppose there are any plans to address this limitation (or later
version already have; I'm on a 1.1.0-SNAPSHOT.jar built from trunk as of
29.03.2008).
Regards,
Michael
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: samedi, 29. mars 2008 03:14
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
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",
joinColumns=@XJoinColumn(name="A_ID"))
private Set<RelB> bs = new HashSet<RelB>();
Thanks!
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: jeudi, 20. mars 2008 17:55
To: users@openjpa.apache.org
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
<mv...@odyssey-group.com> 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.
____________________________________________________________
. 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.
____________________________________________________________
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.
RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Michael Vorburger <mv...@odyssey-group.com>.
Hello again,
Actually, this doesn't work as expected for us after all... limitation:
<openjpa-1.1.0-SNAPSHOT-r422266:641891M fatal user error>
org.apache.openjpa.util.MetaDataException: "X.y<element:class Y>" is
mapped as embedded, but embedded field "..." is not embeddable.
Embedded element/key/value types are limited to simple fields and direct
relations to other persistent types.
The message is clear in what it means, but this actually limits the
usefulness of this somewhat. (A colleague tells me in Hibernate this
kind of mapping is possible.)
I don't suppose there are any plans to address this limitation (or later
version already have; I'm on a 1.1.0-SNAPSHOT.jar built from trunk as of
29.03.2008).
Regards,
Michael
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: samedi, 29. mars 2008 03:14
To: users@openjpa.apache.org
Subject: RE: One-Sided One-Many Mapping, but to different tables -
missing @ElementEmbeddedMapping ?
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",
joinColumns=@XJoinColumn(name="A_ID"))
private Set<RelB> bs = new HashSet<RelB>();
Thanks!
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: jeudi, 20. mars 2008 17:55
To: users@openjpa.apache.org
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
<mv...@odyssey-group.com> 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.
____________________________________________________________
� 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.
RE: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Michael Vorburger <mv...@odyssey-group.com>.
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",
joinColumns=@XJoinColumn(name="A_ID"))
private Set<RelB> bs = new HashSet<RelB>();
Thanks!
-----Original Message-----
From: Patrick Linskey [mailto:plinskey@gmail.com]
Sent: jeudi, 20. mars 2008 17:55
To: users@openjpa.apache.org
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
<mv...@odyssey-group.com> 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.
Re: One-Sided One-Many Mapping, but to different tables - missing @ElementEmbeddedMapping ?
Posted by Patrick Linskey <pl...@gmail.com>.
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
<mv...@odyssey-group.com> 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/manual/
> 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