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:22:39 GMT
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