openjpa-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fay Wang <fyw...@yahoo.com>
Subject RE: NPE at RelationToManyInverseKeyFieldStrategy when using mappedBy inverse
Date Wed, 14 May 2008 16:44:39 GMT
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 <fyw300@yahoo.com> wrote:

> From: Fay Wang <fyw300@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
> <mvorburger@odyssey-group.com> wrote:
> 
> > From: Michael Vorburger
> <mvorburger@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.


      

Mime
View raw message