You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Michael Vorburger <mv...@odyssey-group.com> on 2008/05/14 11:55:01 UTC
RE: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
https://issues.apache.org/jira/browse/OPENJPA-602
-----Original Message-----
From: Michael Vorburger [mailto:mvorburger@odyssey-group.com]
Sent: mercredi, 30. avril 2008 17:07
To: users@openjpa.apache.org; dev@openjpa.apache.org
Subject: NPE at RelationToManyInverseKeyFieldStrategy when using
mappedBy inverse
Hello,
I'm running into an NPE in RelationToManyInverseKeyFieldStrategy
(copy/pasted below) when using an OneToMany inverse relation with
mappedBy and InheritanceType.TABLE_PER_CLASS in 1.1.0-SNAPSHOT...
Test summary: A common abstract superclass Translatable which has a
@OneToManySet<Translation>, and many subclasses of that like e.g. a
SomethingTranslatable, and many more. The idea is that mapping should
lead to a Translation table holding the items for SomethingTranslatable
and all other superclasses. Then SomethingTranslatable and many other
tables (no physical Translatable table). There shouldn't be a join
table for each SomethingTranslatable, as it's a OneToManySet, it doesn't
make sense, so the owning side is a @ManyToOne in Translation back to
Translatable. Granted a physical FK will not be possible in such a
schema - accepted, but it should still be possible to map this? It
works until I use @Inheritance(strategy =
InheritanceType.TABLE_PER_CLASS) on Translatable, with it - boum, NPE.
I have a standalone example (test) demonstrating this that I can put
into a JIRA if anybody wants to have a look (it doesn't make it through
list, or spam filter).
Work-around may be to use a an InheritanceType.JOINED on the
Translatable, which avoids the NPE (tested); and which in this exaxmple
only leads to a basically empty physical Translatable (but allows
physical FK). In the real-world example this is based on though, where
the Translatable has more attributes (e.g. a kind of
shortDefaultTranslation and longDefaultTranslation), and the real
SomethingTranslatable are more complex, this leads to a lot of joins
across a table hiearchy which we'd like to avoid.
Am I doing something wrong? Not possible? Bug? Open a JIRA?
Thanks for any idea, hints, things to try, etc.!
_____________________________
Michael Vorburger, Odyssey Financial Technologies
___
Exception in thread "main" java.lang.NullPointerException at
org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrateg
y.map(RelationToManyInverseKeyFieldStrategy.java:136)
at
org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStr
ategy.map(RelationCollectionInverseKeyFieldStrategy.java:95)
at
org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
120)
at
org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
ntimeStrategyInstaller.java:80)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
va:438)
at
org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:403)
at
org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.ja
va:812)
at
org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1626)
at
org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataReposit
ory.java:717)
at
org.apache.openjpa.meta.MetaDataRepository.resolveMapping(MetaDataReposi
tory.java:677)
at
org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
va:555)
at
org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
y.java:308)
at
org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingReposit
ory.java:284)
at
org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:676
)
at
org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:74
8)
at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:646)
at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1072)
at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:986)
at atest.CreateDBTest.synchronizeDatabase(CreateDBTest.java:70)
at atest.CreateDBTest.testCreateDerbyDB(CreateDBTest.java:31)
at atest.CreateDBTest.main(CreateDBTest.java:35)
____________________________________________________________
* 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: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
Posted by Fay Wang <fy...@yahoo.com>.
I take it back. I found that when I put the fields and methods in EntityBase class directly in the Translatable class instead of having Translatable inherit from EntityBase class, I still get NPE. This problem seems having nothing to do with MappedSuperclass annotation.
-Fay
--- On Wed, 5/14/08, Fay Wang <fy...@yahoo.com> wrote:
> From: Fay Wang <fy...@yahoo.com>
> Subject: RE: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
> To: users@openjpa.apache.org, dev@openjpa.apache.org
> Date: Wednesday, May 14, 2008, 9:22 AM
> Hi Mike,
> Your super class EntityBase is annotated as
> @MappedSuperclass. Your Translatable class which inherits
> from EntityBase has inheritance strategy of
> TABLE_PER_CLASS. Since MappedSuperclass itself is not a
> persistence class and can not act in the capacity of an
> entity, it does not have a corresponding table in the
> database. I think this is why openjpa got confused and
> could not find foreign key between the parent class and the
> child class. When I removed Inheritance strategy annotation
> from Translatable class, your test case went through.
> Having said that, I think the NPE should be fixed and
> proper error message should be thrown.
>
> -Fay
>
>
>
>
>
> --- On Wed, 5/14/08, Michael Vorburger
> <mv...@odyssey-group.com> wrote:
>
> > From: Michael Vorburger
> <mv...@odyssey-group.com>
> > Subject: RE: NPE at
> RelationToManyInverseKeyFieldStrategy when using mappedBy
> inverse
> > To: users@openjpa.apache.org, dev@openjpa.apache.org
> > Date: Wednesday, May 14, 2008, 2:55 AM
> > https://issues.apache.org/jira/browse/OPENJPA-602
> >
> >
> > -----Original Message-----
> > From: Michael Vorburger
> > [mailto:mvorburger@odyssey-group.com]
> > Sent: mercredi, 30. avril 2008 17:07
> > To: users@openjpa.apache.org; dev@openjpa.apache.org
> > Subject: NPE at RelationToManyInverseKeyFieldStrategy
> when
> > using
> > mappedBy inverse
> >
> > Hello,
> >
> > I'm running into an NPE in
> > RelationToManyInverseKeyFieldStrategy
> > (copy/pasted below) when using an OneToMany inverse
> > relation with
> > mappedBy and InheritanceType.TABLE_PER_CLASS in
> > 1.1.0-SNAPSHOT...
> >
> > Test summary: A common abstract superclass
> Translatable
> > which has a
> > @OneToManySet<Translation>, and many subclasses
> of
> > that like e.g. a
> > SomethingTranslatable, and many more. The idea is
> that
> > mapping should
> > lead to a Translation table holding the items for
> > SomethingTranslatable
> > and all other superclasses. Then
> SomethingTranslatable and
> > many other
> > tables (no physical Translatable table). There
> > shouldn't be a join
> > table for each SomethingTranslatable, as it's a
> > OneToManySet, it doesn't
> > make sense, so the owning side is a @ManyToOne in
> > Translation back to
> > Translatable. Granted a physical FK will not be
> possible
> > in such a
> > schema - accepted, but it should still be possible to
> map
> > this? It
> > works until I use @Inheritance(strategy =
> > InheritanceType.TABLE_PER_CLASS) on Translatable, with
> it -
> > boum, NPE.
> >
> > I have a standalone example (test) demonstrating this
> that
> > I can put
> > into a JIRA if anybody wants to have a look (it
> doesn't
> > make it through
> > list, or spam filter).
> >
> > Work-around may be to use a an InheritanceType.JOINED
> on
> > the
> > Translatable, which avoids the NPE (tested); and which
> in
> > this exaxmple
> > only leads to a basically empty physical Translatable
> (but
> > allows
> > physical FK). In the real-world example this is based
> on
> > though, where
> > the Translatable has more attributes (e.g. a kind of
> > shortDefaultTranslation and longDefaultTranslation),
> and
> > the real
> > SomethingTranslatable are more complex, this leads to
> a lot
> > of joins
> > across a table hiearchy which we'd like to avoid.
> >
> > Am I doing something wrong? Not possible? Bug? Open
> a
> > JIRA?
> >
> > Thanks for any idea, hints, things to try, etc.!
> >
> > _____________________________
> > Michael Vorburger, Odyssey Financial Technologies
> >
> > ___
> > Exception in thread "main"
> > java.lang.NullPointerException at
> >
> org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrateg
> > y.map(RelationToManyInverseKeyFieldStrategy.java:136)
> > at
> >
> org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStr
> >
> ategy.map(RelationCollectionInverseKeyFieldStrategy.java:95)
> > at
> >
> org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
> > 120)
> > at
> >
> org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
> > ntimeStrategyInstaller.java:80)
> > at
> >
> org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
> > va:438)
> > at
> >
> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:403)
> > at
> >
> org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.ja
> > va:812)
> > at
> >
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1626)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataReposit
> > ory.java:717)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.resolveMapping(MetaDataReposi
> > tory.java:677)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
> > va:555)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
> > y.java:308)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingReposit
> > ory.java:284)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:676
> > )
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:74
> > 8)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:646)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1072)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:986)
> > at
> >
> atest.CreateDBTest.synchronizeDatabase(CreateDBTest.java:70)
> > at
> >
> atest.CreateDBTest.testCreateDerbyDB(CreateDBTest.java:31)
> > at atest.CreateDBTest.main(CreateDBTest.java:35)
> >
> >
> >
> >
> ____________________________________________________________
> >
> > * 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: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
Posted by Fay Wang <fy...@yahoo.com>.
I take it back. I found that when I put the fields and methods in EntityBase class directly in the Translatable class instead of having Translatable inherit from EntityBase class, I still get NPE. This problem seems having nothing to do with MappedSuperclass annotation.
-Fay
--- On Wed, 5/14/08, Fay Wang <fy...@yahoo.com> wrote:
> From: Fay Wang <fy...@yahoo.com>
> Subject: RE: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
> To: users@openjpa.apache.org, dev@openjpa.apache.org
> Date: Wednesday, May 14, 2008, 9:22 AM
> Hi Mike,
> Your super class EntityBase is annotated as
> @MappedSuperclass. Your Translatable class which inherits
> from EntityBase has inheritance strategy of
> TABLE_PER_CLASS. Since MappedSuperclass itself is not a
> persistence class and can not act in the capacity of an
> entity, it does not have a corresponding table in the
> database. I think this is why openjpa got confused and
> could not find foreign key between the parent class and the
> child class. When I removed Inheritance strategy annotation
> from Translatable class, your test case went through.
> Having said that, I think the NPE should be fixed and
> proper error message should be thrown.
>
> -Fay
>
>
>
>
>
> --- On Wed, 5/14/08, Michael Vorburger
> <mv...@odyssey-group.com> wrote:
>
> > From: Michael Vorburger
> <mv...@odyssey-group.com>
> > Subject: RE: NPE at
> RelationToManyInverseKeyFieldStrategy when using mappedBy
> inverse
> > To: users@openjpa.apache.org, dev@openjpa.apache.org
> > Date: Wednesday, May 14, 2008, 2:55 AM
> > https://issues.apache.org/jira/browse/OPENJPA-602
> >
> >
> > -----Original Message-----
> > From: Michael Vorburger
> > [mailto:mvorburger@odyssey-group.com]
> > Sent: mercredi, 30. avril 2008 17:07
> > To: users@openjpa.apache.org; dev@openjpa.apache.org
> > Subject: NPE at RelationToManyInverseKeyFieldStrategy
> when
> > using
> > mappedBy inverse
> >
> > Hello,
> >
> > I'm running into an NPE in
> > RelationToManyInverseKeyFieldStrategy
> > (copy/pasted below) when using an OneToMany inverse
> > relation with
> > mappedBy and InheritanceType.TABLE_PER_CLASS in
> > 1.1.0-SNAPSHOT...
> >
> > Test summary: A common abstract superclass
> Translatable
> > which has a
> > @OneToManySet<Translation>, and many subclasses
> of
> > that like e.g. a
> > SomethingTranslatable, and many more. The idea is
> that
> > mapping should
> > lead to a Translation table holding the items for
> > SomethingTranslatable
> > and all other superclasses. Then
> SomethingTranslatable and
> > many other
> > tables (no physical Translatable table). There
> > shouldn't be a join
> > table for each SomethingTranslatable, as it's a
> > OneToManySet, it doesn't
> > make sense, so the owning side is a @ManyToOne in
> > Translation back to
> > Translatable. Granted a physical FK will not be
> possible
> > in such a
> > schema - accepted, but it should still be possible to
> map
> > this? It
> > works until I use @Inheritance(strategy =
> > InheritanceType.TABLE_PER_CLASS) on Translatable, with
> it -
> > boum, NPE.
> >
> > I have a standalone example (test) demonstrating this
> that
> > I can put
> > into a JIRA if anybody wants to have a look (it
> doesn't
> > make it through
> > list, or spam filter).
> >
> > Work-around may be to use a an InheritanceType.JOINED
> on
> > the
> > Translatable, which avoids the NPE (tested); and which
> in
> > this exaxmple
> > only leads to a basically empty physical Translatable
> (but
> > allows
> > physical FK). In the real-world example this is based
> on
> > though, where
> > the Translatable has more attributes (e.g. a kind of
> > shortDefaultTranslation and longDefaultTranslation),
> and
> > the real
> > SomethingTranslatable are more complex, this leads to
> a lot
> > of joins
> > across a table hiearchy which we'd like to avoid.
> >
> > Am I doing something wrong? Not possible? Bug? Open
> a
> > JIRA?
> >
> > Thanks for any idea, hints, things to try, etc.!
> >
> > _____________________________
> > Michael Vorburger, Odyssey Financial Technologies
> >
> > ___
> > Exception in thread "main"
> > java.lang.NullPointerException at
> >
> org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrateg
> > y.map(RelationToManyInverseKeyFieldStrategy.java:136)
> > at
> >
> org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStr
> >
> ategy.map(RelationCollectionInverseKeyFieldStrategy.java:95)
> > at
> >
> org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
> > 120)
> > at
> >
> org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
> > ntimeStrategyInstaller.java:80)
> > at
> >
> org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
> > va:438)
> > at
> >
> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:403)
> > at
> >
> org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.ja
> > va:812)
> > at
> >
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1626)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataReposit
> > ory.java:717)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.resolveMapping(MetaDataReposi
> > tory.java:677)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
> > va:555)
> > at
> >
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
> > y.java:308)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingReposit
> > ory.java:284)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:676
> > )
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:74
> > 8)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:646)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1072)
> > at
> >
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:986)
> > at
> >
> atest.CreateDBTest.synchronizeDatabase(CreateDBTest.java:70)
> > at
> >
> atest.CreateDBTest.testCreateDerbyDB(CreateDBTest.java:31)
> > at atest.CreateDBTest.main(CreateDBTest.java:35)
> >
> >
> >
> >
> ____________________________________________________________
> >
> > * 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: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
Posted by Fay Wang <fy...@yahoo.com>.
Hi Mike,
Your super class EntityBase is annotated as @MappedSuperclass. Your Translatable class which inherits from EntityBase has inheritance strategy of TABLE_PER_CLASS. Since MappedSuperclass itself is not a persistence class and can not act in the capacity of an entity, it does not have a corresponding table in the database. I think this is why openjpa got confused and could not find foreign key between the parent class and the child class. When I removed Inheritance strategy annotation from Translatable class, your test case went through. Having said that, I think the NPE should be fixed and proper error message should be thrown.
-Fay
--- On Wed, 5/14/08, Michael Vorburger <mv...@odyssey-group.com> wrote:
> From: Michael Vorburger <mv...@odyssey-group.com>
> Subject: RE: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
> To: users@openjpa.apache.org, dev@openjpa.apache.org
> Date: Wednesday, May 14, 2008, 2:55 AM
> https://issues.apache.org/jira/browse/OPENJPA-602
>
>
> -----Original Message-----
> From: Michael Vorburger
> [mailto:mvorburger@odyssey-group.com]
> Sent: mercredi, 30. avril 2008 17:07
> To: users@openjpa.apache.org; dev@openjpa.apache.org
> Subject: NPE at RelationToManyInverseKeyFieldStrategy when
> using
> mappedBy inverse
>
> Hello,
>
> I'm running into an NPE in
> RelationToManyInverseKeyFieldStrategy
> (copy/pasted below) when using an OneToMany inverse
> relation with
> mappedBy and InheritanceType.TABLE_PER_CLASS in
> 1.1.0-SNAPSHOT...
>
> Test summary: A common abstract superclass Translatable
> which has a
> @OneToManySet<Translation>, and many subclasses of
> that like e.g. a
> SomethingTranslatable, and many more. The idea is that
> mapping should
> lead to a Translation table holding the items for
> SomethingTranslatable
> and all other superclasses. Then SomethingTranslatable and
> many other
> tables (no physical Translatable table). There
> shouldn't be a join
> table for each SomethingTranslatable, as it's a
> OneToManySet, it doesn't
> make sense, so the owning side is a @ManyToOne in
> Translation back to
> Translatable. Granted a physical FK will not be possible
> in such a
> schema - accepted, but it should still be possible to map
> this? It
> works until I use @Inheritance(strategy =
> InheritanceType.TABLE_PER_CLASS) on Translatable, with it -
> boum, NPE.
>
> I have a standalone example (test) demonstrating this that
> I can put
> into a JIRA if anybody wants to have a look (it doesn't
> make it through
> list, or spam filter).
>
> Work-around may be to use a an InheritanceType.JOINED on
> the
> Translatable, which avoids the NPE (tested); and which in
> this exaxmple
> only leads to a basically empty physical Translatable (but
> allows
> physical FK). In the real-world example this is based on
> though, where
> the Translatable has more attributes (e.g. a kind of
> shortDefaultTranslation and longDefaultTranslation), and
> the real
> SomethingTranslatable are more complex, this leads to a lot
> of joins
> across a table hiearchy which we'd like to avoid.
>
> Am I doing something wrong? Not possible? Bug? Open a
> JIRA?
>
> Thanks for any idea, hints, things to try, etc.!
>
> _____________________________
> Michael Vorburger, Odyssey Financial Technologies
>
> ___
> Exception in thread "main"
> java.lang.NullPointerException at
> org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrateg
> y.map(RelationToManyInverseKeyFieldStrategy.java:136)
> at
> org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStr
> ategy.map(RelationCollectionInverseKeyFieldStrategy.java:95)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
> 120)
> at
> org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
> ntimeStrategyInstaller.java:80)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
> va:438)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:403)
> at
> org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.ja
> va:812)
> at
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1626)
> at
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataReposit
> ory.java:717)
> at
> org.apache.openjpa.meta.MetaDataRepository.resolveMapping(MetaDataReposi
> tory.java:677)
> at
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
> va:555)
> at
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
> y.java:308)
> at
> org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingReposit
> ory.java:284)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:676
> )
> at
> org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:74
> 8)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:646)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1072)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:986)
> at
> atest.CreateDBTest.synchronizeDatabase(CreateDBTest.java:70)
> at
> atest.CreateDBTest.testCreateDerbyDB(CreateDBTest.java:31)
> at atest.CreateDBTest.main(CreateDBTest.java:35)
>
>
>
> ____________________________________________________________
>
> * 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: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
Posted by Fay Wang <fy...@yahoo.com>.
Hi Mike,
Your super class EntityBase is annotated as @MappedSuperclass. Your Translatable class which inherits from EntityBase has inheritance strategy of TABLE_PER_CLASS. Since MappedSuperclass itself is not a persistence class and can not act in the capacity of an entity, it does not have a corresponding table in the database. I think this is why openjpa got confused and could not find foreign key between the parent class and the child class. When I removed Inheritance strategy annotation from Translatable class, your test case went through. Having said that, I think the NPE should be fixed and proper error message should be thrown.
-Fay
--- On Wed, 5/14/08, Michael Vorburger <mv...@odyssey-group.com> wrote:
> From: Michael Vorburger <mv...@odyssey-group.com>
> Subject: RE: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
> To: users@openjpa.apache.org, dev@openjpa.apache.org
> Date: Wednesday, May 14, 2008, 2:55 AM
> https://issues.apache.org/jira/browse/OPENJPA-602
>
>
> -----Original Message-----
> From: Michael Vorburger
> [mailto:mvorburger@odyssey-group.com]
> Sent: mercredi, 30. avril 2008 17:07
> To: users@openjpa.apache.org; dev@openjpa.apache.org
> Subject: NPE at RelationToManyInverseKeyFieldStrategy when
> using
> mappedBy inverse
>
> Hello,
>
> I'm running into an NPE in
> RelationToManyInverseKeyFieldStrategy
> (copy/pasted below) when using an OneToMany inverse
> relation with
> mappedBy and InheritanceType.TABLE_PER_CLASS in
> 1.1.0-SNAPSHOT...
>
> Test summary: A common abstract superclass Translatable
> which has a
> @OneToManySet<Translation>, and many subclasses of
> that like e.g. a
> SomethingTranslatable, and many more. The idea is that
> mapping should
> lead to a Translation table holding the items for
> SomethingTranslatable
> and all other superclasses. Then SomethingTranslatable and
> many other
> tables (no physical Translatable table). There
> shouldn't be a join
> table for each SomethingTranslatable, as it's a
> OneToManySet, it doesn't
> make sense, so the owning side is a @ManyToOne in
> Translation back to
> Translatable. Granted a physical FK will not be possible
> in such a
> schema - accepted, but it should still be possible to map
> this? It
> works until I use @Inheritance(strategy =
> InheritanceType.TABLE_PER_CLASS) on Translatable, with it -
> boum, NPE.
>
> I have a standalone example (test) demonstrating this that
> I can put
> into a JIRA if anybody wants to have a look (it doesn't
> make it through
> list, or spam filter).
>
> Work-around may be to use a an InheritanceType.JOINED on
> the
> Translatable, which avoids the NPE (tested); and which in
> this exaxmple
> only leads to a basically empty physical Translatable (but
> allows
> physical FK). In the real-world example this is based on
> though, where
> the Translatable has more attributes (e.g. a kind of
> shortDefaultTranslation and longDefaultTranslation), and
> the real
> SomethingTranslatable are more complex, this leads to a lot
> of joins
> across a table hiearchy which we'd like to avoid.
>
> Am I doing something wrong? Not possible? Bug? Open a
> JIRA?
>
> Thanks for any idea, hints, things to try, etc.!
>
> _____________________________
> Michael Vorburger, Odyssey Financial Technologies
>
> ___
> Exception in thread "main"
> java.lang.NullPointerException at
> org.apache.openjpa.jdbc.meta.strats.RelationToManyInverseKeyFieldStrateg
> y.map(RelationToManyInverseKeyFieldStrategy.java:136)
> at
> org.apache.openjpa.jdbc.meta.strats.RelationCollectionInverseKeyFieldStr
> ategy.map(RelationCollectionInverseKeyFieldStrategy.java:95)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.setStrategy(FieldMapping.java:
> 120)
> at
> org.apache.openjpa.jdbc.meta.RuntimeStrategyInstaller.installStrategy(Ru
> ntimeStrategyInstaller.java:80)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolveMapping(FieldMapping.ja
> va:438)
> at
> org.apache.openjpa.jdbc.meta.FieldMapping.resolve(FieldMapping.java:403)
> at
> org.apache.openjpa.jdbc.meta.ClassMapping.resolveMapping(ClassMapping.ja
> va:812)
> at
> org.apache.openjpa.meta.ClassMetaData.resolve(ClassMetaData.java:1626)
> at
> org.apache.openjpa.meta.MetaDataRepository.processBuffer(MetaDataReposit
> ory.java:717)
> at
> org.apache.openjpa.meta.MetaDataRepository.resolveMapping(MetaDataReposi
> tory.java:677)
> at
> org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.ja
> va:555)
> at
> org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepositor
> y.java:308)
> at
> org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingReposit
> ory.java:284)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:676
> )
> at
> org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:74
> 8)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:646)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:1072)
> at
> org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:986)
> at
> atest.CreateDBTest.synchronizeDatabase(CreateDBTest.java:70)
> at
> atest.CreateDBTest.testCreateDerbyDB(CreateDBTest.java:31)
> at atest.CreateDBTest.main(CreateDBTest.java:35)
>
>
>
> ____________________________________________________________
>
> * 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.