2.2.1 bug when using COUNT and TYPE?
We have a JPQL query that is like this: SELECT COUNT(s.id) FROM SubsidiaryDetail s JOIN s.accountEntry a JOIN a.journalEntry j WHERE j.id = :journalEntryId AND s.amount <> 0 AND TYPE(s) NOT IN (ARSubsidiaryDetail) As you can hopefully see SubsidiaryDetail is a supertype; ARSubsidiaryDetailis a subtype. So far so good. The (mysterious) SQL that comes out of OpenJPA 2.2.1 is: SELECT *t3.id*, COUNT(t0.id) FROM ngp.subsidiary_detail t0 INNER JOIN ngp.account_entry t1 ON t0.account_entry_id = t1.id INNER JOIN ngp-journal_entry t2 ON t1.journal_entry_id = t2.id, *ngp.ar_subsidiary_detail t3* // < this is suspect; no join? WHERE (t1.journal_entry_id = ? AND t0.amount <> ? AND t0.DTYPE = 'AR' AND 1 = 1) Note line 5, which appears to be inserting the subtype table as another element of the FROM clause, not as an INNER JOIN. Note as well that this t3alias then shows up in the SELECT clause. Where do I begin untangling this? Best, Laird -- http://about.me/lairdnelson
join-bad-col message key doesn't have corresponding message text
I'm getting a metadata validation error and OpenJPA 2.2.1 is attempting to tell me something I'm sure is helpful, but the message key in question ( join-bad-col) does not appear to have a related message. Here's the root error I'm getting: Caused by: org.apache.openjpa.persistence.ArgumentException: localized message key: * join-bad-col*; substitutions: [com.foobar.RelationshipRecordBeanImpl.activeOn, bigint, Full Name: rel_table.REL Type: char Size: 4 Default: null Not Null: true ] at org.apache.openjpa.jdbc.meta.MappingInfo.mergeColumn(MappingInfo.java:775) What is this error trying to tell me? I know it's going to have to do with a @SecondaryTable annotation that is in play and probably its related @PrimaryKeyJoinColumn annotation, but to my eyes everything looks OK. Thanks, Laird -- http://about.me/lairdnelson
Re: EntityManager#createNamedQuery(String, Class) problem
On Tue, Oct 25, 2011 at 1:31 PM, Laird Nelson wrote:
> I've got a case where I'm building a query like this:
>
> TypedQuery q = em.createNamedQuery("someQuery",
> SomeInterface.class);
>
> Now, SomeInterface is not the actual entity class--that would be
> SomeInterfaceEntity (not mentioned above, as you'll note). But it is an
> interface that the results of the query all implement.
>
> EclipseLink and Hibernate both accept this declaration just fine and run
> the associated query just fine.
>
> At runtime, this version of OpenJPA seems to be trying to treat
> SomeInterface.class as though it denoted an entity:
>
>
> org.apache.openjpa.persistence.ArgumentException: Result type "interface
> com.foobar.SomeInterface" does not have any public fields or setter methods
> for the projection or aggregate result element "SomeInterfaceEntity", nor
> does it have a generic put(Object,Object) method that can be used, nor does
> it have a public constructor that takes the types null.
>
I've filed https://issues.apache.org/jira/browse/OPENJPA-2065 to track
this. Has anyone else run into this issue?
Best,
Laird
--
http://about.me/lairdnelson
EntityManager#createNamedQuery(String, Class) problem
We're using OpenJPA 2.1.0.
I've got a case where I'm building a query like this:
TypedQuery q = em.createNamedQuery("someQuery",
SomeInterface.class);
Now, SomeInterface is not the actual entity class--that would be
SomeInterfaceEntity (not mentioned above, as you'll note). But it is an
interface that the results of the query all implement.
EclipseLink and Hibernate both accept this declaration just fine and run the
associated query just fine.
At runtime, this version of OpenJPA seems to be trying to treat
SomeInterface.class as though it denoted an entity:
org.apache.openjpa.persistence.ArgumentException: Result type "interface
com.foobar.SomeInterface" does not have any public fields or setter methods
for the projection or aggregate result element "SomeInterfaceEntity", nor
does it have a generic put(Object,Object) method that can be used, nor does
it have a public constructor that takes the types null.
at org.apache.openjpa.kernel.ResultPacker.(ResultPacker.java:158)
at org.apache.openjpa.kernel.ResultPacker.(ResultPacker.java:103)
at
org.apache.openjpa.kernel.QueryImpl.getResultPacker(QueryImpl.java:1289)
at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1228)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1005)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:861)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:792)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:542)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:288)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:302)
Truth be told, I have no idea what OpenJPA is trying to tell me here.
JPA's Javadoc places no restrictions on the class passed in as the second
argument to EntityManager#createNamedQuery(String,
Class).
The JPA specification doesn't do so either, at least in the sections I read
concerning queries.
I am also using (I know, I know) subclass-based enhancement.
What...are my options here?
Best,
Laird
--
http://about.me/lairdnelson
Running PCEnhancer on a pile of classes that are not all entities
I wanted to verify that this ominous PCEnhancer warning: 3294 weaving WARN [main] openjpa.Enhance - Type "class > com.foobar.FoobarPropertyEditor" loaded by > org.apache.openjpa.lib.util.TemporaryClassLoader@5fd1358f has no metadata; > enhancing as persistence aware. If you intended for "class > com.FoobarPropertyEditor" to be persistence-capable, then this means that > OpenJPA could not find any metadata for "class > com.foobar.FoobarPropertyEditor". This can happen if the directory > containing your metadata is not in your CLASSPATH, or if your metadata files > are not named properly. See the documentation on metadata placement for more > information. > ...simply means that the OpenJPA PCEnhancer effectively took no action on the class in question. I am running the PCEnhancer through Ant as invoked by the maven-antrun-plugin; I have opted to run it over a directory tree (via Ant's element) rather than specifying the files in the persistence.xml. For various reasons, this means that among the many .classfiles in the directory tree are classes that are not entities. I want to make sure that they are not being modified in any way. I looked at the .class file in emacs and didn't see anything obvious. Best, Laird -- http://about.me/lairdnelson
TableGenerator: interesting unspecified behavior?
The JPA specification is silent on the issue of what should happen if a @TableGenerator refers to a table with no rows in it. OpenJPA does the sensible thing, which is to insert a new row, with the specified pkColumnValue and initialValue in it. Hibernate appears to do this as well. However, EclipseLink does not do this. Did the OpenJPA folks do this because they thought it was a nice thing to do, or because they were under the impression the specification implied it? Thanks, Laird -- http://about.me/lairdnelson
OpenJPA does not read default schema from orm.xml for TableGenerator-specified sequence table
I have a @TableGenerator annotation that does not specify a schema:
@javax.persistence.TableGenerator(
name = "Fund",
table = "jpa_sequence",
pkColumnName = "sequence_name",
valueColumnName = "last_value",
pkColumnValue = "Fund",
allocationSize = 500
)
I have a persistence-unit-defaults stanza in my META-INF/orm.xml that DOES
specify a default schema:
http://java.sun.com/xml/ns/persistence/orm";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence/orm
http://java.sun.com/xml/ns/persistence/orm_2_0.xsd";
version="2.0">
ngp
OpenJPA does not use this default schema when working with the sequence
table described by my @TableGenerator annotation. IMHO it should. See the
stack:
org.apache.openjpa.persistence.PersistenceException: Table "JPA_SEQUENCE"
not found; SQL statement:
SELECT LAST_VALUE FROM jpa_sequence WHERE SEQUENCE_NAME = ? FOR UPDATE
[42102-151] {SELECT LAST_VALUE FROM jpa_sequence WHERE SEQUENCE_NAME = ? FOR
UPDATE} [code=42102, state=42S02]
at
org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4869)
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4829)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:136)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:110)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:62)
at
org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.next(AbstractJDBCSeq.java:66)
at org.apache.openjpa.util.ImplHelper.generateValue(ImplHelper.java:160)
at
org.apache.openjpa.util.ImplHelper.generateFieldValue(ImplHelper.java:144)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignField(JDBCStoreManager.java:785)
at
org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:493)
at
org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:769)
at
org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
at
org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:605)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2966)
at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:40)
at
org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:1047)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2091)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2051)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1822)
at
org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:1037)
at
org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:654)
My default schema is supposed to be "ngp". EclipseLink works fine here (and
has for several versions). Hibernate suffers from the same bug (
https://hibernate.onjira.com/browse/HHH-5235) and in grand Hibernate fashion
shows no signs of ever fixing it. Should I file a bug here, or have I
misunderstood the specification?
Best,
Laird
--
http://about.me/lairdnelson
Re: GenerationType.TABLE question: column name suffixed with 0?
On Fri, Aug 26, 2011 at 1:49 PM, Laird Nelson wrote: > OpenJPA tries to read a column called "NAME0", which is not defined > anywhere. > Changing the name of the sequence table column from "NAME" to "SEQUENCE_NAME" fixed the problem. Bug in OpenJPA, I think. Maybe in the H2 dictionary? Best, Laird -- http://about.me/lairdnelson
GenerationType.TABLE question: column name suffixed with 0?
I'm seeing some odd trace output in OpenJPA 2.1.0 when attempting to grab a
value from a sequence table I've set up (via the @TableGeneratorannotation).
I have created a table named ngp.jpa_sequence with two columns: name and
last_value. name is a varchar(100); last_value is a bigint. name is the
primary key. Both columns are non-nullable. This is in the H2 database,
v1.3.158, if it matters.
My @TableGenerator looks like this:
@javax.persistence.TableGenerator(
name = "fred",
table = "jpa_sequence",
pkColumnName = "name",
valueColumnName = "last_value",
pkColumnValue = "fred",
allocationSize = 500
)
My @GeneratedValue looks like this:
@javax.persistence.GeneratedValue(strategy =
javax.persistence.GenerationType.TABLE, generator = "fred")
OpenJPA tries to read a column called "NAME0", which is not defined
anywhere.
OpenJPA begins setting up, and then it does this (huge stack; stand back):
org.apache.openjpa.persistence.PersistenceException: Column "NAME0" not
found; SQL statement:
SELECT LAST_VALUE FROM ngp.jpa_sequence WHERE NAME0 = ? FOR UPDATE
[42122-151] {SELECT LAST_VALUE FROM ngp.jpa_sequence WHERE NAME0 = ? FOR
UPDATE} [code=42122, state=42S22]
at
org.apache.openjpa.jdbc.sql.DBDictionary.narrow(DBDictionary.java:4869)
at
org.apache.openjpa.jdbc.sql.DBDictionary.newStoreException(DBDictionary.java:4829)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:136)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:110)
at
org.apache.openjpa.jdbc.sql.SQLExceptions.getStore(SQLExceptions.java:62)
at
org.apache.openjpa.jdbc.kernel.AbstractJDBCSeq.next(AbstractJDBCSeq.java:66)
at org.apache.openjpa.util.ImplHelper.generateValue(ImplHelper.java:160)
at
org.apache.openjpa.util.ImplHelper.generateFieldValue(ImplHelper.java:144)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignField(JDBCStoreManager.java:785)
at
org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:493)
at
org.apache.openjpa.util.ApplicationIds.assign(ApplicationIds.java:469)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreManager.assignObjectId(JDBCStoreManager.java:769)
at
org.apache.openjpa.kernel.DelegatingStoreManager.assignObjectId(DelegatingStoreManager.java:135)
at
org.apache.openjpa.kernel.StateManagerImpl.assignObjectId(StateManagerImpl.java:605)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2966)
at org.apache.openjpa.kernel.PNewState.beforeFlush(PNewState.java:40)
at
org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:1047)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:2091)
at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:2051)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1822)
at
org.apache.openjpa.kernel.DelegatingBroker.flush(DelegatingBroker.java:1037)
at
org.apache.openjpa.persistence.EntityManagerImpl.flush(EntityManagerImpl.java:654)
at com.foo.TestCaseFoobar.testInsert(TestCaseFoobar.java:40)
[snip]
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException: Column "NAME0"
not found; SQL statement:
SELECT LAST_VALUE FROM ngp.jpa_sequence WHERE NAME0 = ? FOR UPDATE
[42122-151] {SELECT LAST_VALUE FROM ngp.jpa_sequence WHERE NAME0 = ? FOR
UPDATE} [code=42122, state=42S22]
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:281)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.wrap(LoggingConnectionDecorator.java:261)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator.access$000(LoggingConnectionDecorator.java:72)
at
org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection.prepareStatement(LoggingConnectionDecorator.java:313)
at
org.apache.openjpa.lib.jdbc.DelegatingConnection.prepareStatement(DelegatingConnection.java:155)
at
org.apache.openjpa.lib.jdbc.ConfiguringConnectionDecorator$ConfiguringConnection.prepareStatement(ConfiguringConnectionDecorator.java:158)
at
org.apache.openjpa.lib.jdbc.DelegatingConnection.prepareStatement(DelegatingConnection.java:144)
at
org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:561)
at
org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:541)
at
org.apache.openjpa.jdbc.sql.SQLBuffer.prepareStatement(SQLBuffer.java:530)
at
org.apache.openjpa.jdbc.kernel.TableJDBCSeq.prepareStatement(TableJDBCSeq.java:807)
at
org.apache.openjpa.jdbc.kernel.TableJDBCSeq.getSequence(TableJDBCSeq.java:546)
at
org.apache.openjpa.jdbc.kernel.TableJDBCSeq.setSequence(TableJDBCSeq.java:588)
at
org.apache.openjpa.jdbc.kernel.TableJDBCSeq$AllocateSequenceRunnable.run(TableJDBCSeq.java:893)
at
org.apache.openjpa.jdbc.kernel.TableJDBCSeq.allocateSequence(TableJDBCSeq.java:455)
at
org.apache.openjpa.jdbc.kernel.TableJDBCSeq.nextInternal(TableJDBCSeq.java:300
Documentation link broken?
http://openjpa.apache.org/builds/apache-openjpa-2.1.1/docs/manual/manual.htmlgives me a 404. This is the link off the main Documentation page. Thought someone should know. Best, Laird -- http://about.me/lairdnelson
Quieting the "OpenJPA will not be used" warning message
For a whole host of unimportant reasons, we end up getting this message output by OpenJPA 2.0.0: INFO: Found persistence provider "org.hibernate.ejb.HibernatePersistence". OpenJPA will not be used. (We run unit tests against all the major JPA providers; hence sometimes other persistence providers show up. This is expected, and not a cause for concern for us.) I have logging throttled down for everything in our production build, but I cannot stop OpenJPA from spitting out this message. My logging statement is: DefaultLevel=ERROR ...with no further modifications. This correctly shuts OpenJPA up, but I can't silence the message cited above. Any help is appreciated. Best, Laird
Default schema question (yes, I know about the Schema property)
I have a test suite that runs my JPA entities across all the major JPA providers. None of my entities has a schema name in it; I want to keep it that way. None of my entities are configured in any way other than annotations. I understand from the JPA specification that if I put in a element in my META-INF/orm.xml file, I can indicate a default catalog and a default schema to use. When I do this, indeed my EclipseLink and Hibernate tests pass. My OpenJPA tests fail. I then read this: http://openjpa.208410.n2.nabble.com/best-way-to-set-default-schema-across-all-entities-td215796.html I believe this is a misinterpretation of the specification. Is there any way to get OpenJPA to honor the persistence-unit-defaults element in the orm.xml file and to apply it to entities that are not listed therein? I am using OpenJPA 2.0.0-beta3 (not 2.0.1, since that has a NullPointerException regression in named queries which I previously documented). Best, Laird
Re: NullPointerException regression in JDBCStoreManager 2.0.0-beta3 --> 2.0.1
Correction: the regression was introduced from 2.0.0-beta3 to 2.0.0. Best, Laird On Mon, Nov 1, 2010 at 3:50 PM, Laird Nelson wrote: > setInverseRelation, line 469. > > In version 2.0.0-beta3, this all worked fine. > > In version 2.0.1 any named query I create blows up with a stack like the > following: > > FailedObject: SELECT j FROM JournalEntry j WHERE j.status <> :voidedEntry > AND j.effectiveOn >= :beginOn AND j.effectiveOn <= :endOn AND j.id IN > (SELECT DISTINCT d.accountEntry.journalEntry.id FROM SubsidiaryDetail d > WHERE d.constituentId = :constituentId) ORDER BY j.effectiveOn DESC > [java.lang.String] > at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:986) > at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:885) > at > org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1030) > at > org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:280) > at > org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2344) > at > org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:274) > at > org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59) > at > org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:36) > at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1246) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1005) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:861) > at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:792) > at > org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:542) > at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:288) > at > org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:302) > at > com.jenzabar.ngp.financial.accounting.jpa.TestCaseJournalEntryEntity.testFindEntryStudent(TestCaseJournalEntryEntity.java:222) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) > at org.junit.runners.ParentRunner.run(ParentRunner.java:236) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) > at > org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145) > at org.apache.maven.surefire.Surefire.run(Surefire.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method
NullPointerException regression in JDBCStoreManager 2.0.0-beta3 --> 2.0.1
setInverseRelation, line 469. In version 2.0.0-beta3, this all worked fine. In version 2.0.1 any named query I create blows up with a stack like the following: FailedObject: SELECT j FROM JournalEntry j WHERE j.status <> :voidedEntry AND j.effectiveOn >= :beginOn AND j.effectiveOn <= :endOn AND j.id IN (SELECT DISTINCT d.accountEntry.journalEntry.id FROM SubsidiaryDetail d WHERE d.constituentId = :constituentId) ORDER BY j.effectiveOn DESC [java.lang.String] at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:986) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:885) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.load(JDBCStoreManager.java:1030) at org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:280) at org.apache.openjpa.jdbc.sql.SelectImpl$SelectResult.load(SelectImpl.java:2344) at org.apache.openjpa.jdbc.sql.AbstractResult.load(AbstractResult.java:274) at org.apache.openjpa.jdbc.kernel.InstanceResultObjectProvider.getResultObject(InstanceResultObjectProvider.java:59) at org.apache.openjpa.lib.rop.EagerResultList.(EagerResultList.java:36) at org.apache.openjpa.kernel.QueryImpl.toResult(QueryImpl.java:1246) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:1005) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:861) at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:792) at org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:542) at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:288) at org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:302) at com.jenzabar.ngp.financial.accounting.jpa.TestCaseJournalEntryEntity.testFindEntryStudent(TestCaseJournalEntryEntity.java:222) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:76) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.junit.runners.Suite.runChild(Suite.java:128) at org.junit.runners.Suite.runChild(Suite.java:24) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184) at org.junit.runners.ParentRunner.run(ParentRunner.java:236) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:145) at org.apache.maven.surefire.Surefire.run(Surefire.java:104) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1017) Caused by: java.lang.NullPointerException at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.setInverseRelation(JDBCStoreManager.java:469) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initializeState(JDBCStoreManager.java:429) at org.apache.openjpa.jdbc.kernel.JDBCStoreManager.initialize(JDBCStoreManager.java:322) at org.apache.openjpa.kernel.Delegating
Re: NoClassDefFoundError in JavaSE environment
Interestingly, when I crank the logging up, and when OpenJPA is reporting its properties, it says: openjpa.RuntimeUnenhancedClasses: 0 Like I said, I have ...in my persistence.xml. Is something happening here? Thanks, Laird On Wed, May 12, 2010 at 4:00 PM, Laird Nelson wrote: > I'm getting an odd NoClassDefFoundError while running unit tests in a > standard Java SE environment. I'm on Java 6 with OpenJPA 2.0.0-beta3. > > I have an AbstractType class that is a @MappedSuperclass. It is in one jar > file. > It contains, among other things, an @Id mapping, and a couple of > straightforward @Basic/@Column mappings (no joins, no embeddables, nothing > complicated). > > Then I have a class, RelationshipRoleTypeEntity, that extends from it. It > is an @Entity and adds no additional persistent fields. > > The jar file and the classpath root containing my > RelationshipRoleTypeEntity.class are both on the classpath. > > Hibernate loads and runs this fine. > > OpenJPA says: > > java.lang.NoClassDefFoundError: Could not initialize class > com.jenzabar.ngp.constituent.jpa.RelationshipRoleTypeEntity > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:247) > at > org.apache.openjpa.meta.MetaDataRepository.classForName(MetaDataRepository.java:1525) > at > org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypesInternal(MetaDataRepository.java:1501) > at > org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(MetaDataRepository.java:1479) > at > org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(MetaDataRepository.java:1459) > at > org.apache.openjpa.jdbc.meta.MappingRepository.findBaseClassMapping(MappingRepository.java:1516) > at > org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping(MappingRepository.java:403) > at > org.apache.openjpa.meta.MetaDataRepository.preMapping(MetaDataRepository.java:736) > at > org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:625) > at > org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:385) > at > org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:358) > at > org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:355) > at > org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:679) > at > org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:751) > at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:649) > at > org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:149) > at > org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:159) > at > org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl(JDBCBrokerFactory.java:117) > at > org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:199) > at > org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:156) > at > org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:213) > at > org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:151) > at > org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:57) > > I've found that often this means that I've forgotten to put a > xyz entry in my persistence.xml, but that is present as well. > > Other interesting bits in the log before the ultimate error: > > 1328 test-OpenJPA TRACE [main] openjpa.Enhance - Enhancing type "class > com.jenzabar.ngp.constituent.jpa.RelationshipRoleTypeEntity" loaded by > org.apache.openjpa.lib.util.temporaryclassloa...@1b4c1d7. > 1735 test-OpenJPA WARN [main] openjpa.MetaData - The class > "com.jenzabar.ngp.constituent.jpa.RelationshipRoleTypeEntity" listed in the > openjpa.MetaDataFactory configuration property could not be loaded by > sun.misc.launcher$appclassloa...@35ce36; ignoring. > 1735 test-OpenJPA TRACE [main] openjpa.MetaData - > java.lang.NoSuchMethodError: > com.jenzabar.ngp.identity.jpa.AbstractType.pcGetManagedFieldCount()I > java.lang.NoSuchMethodError: > com.jenzabar.ngp.identity.jpa.AbstractType.pcGetManagedFieldCount()I > > > I have the property openjpa.RuntimeUnenhancedClasses="supported" set > because I am running in a unit test environment where I vet my mappings > against Hibernate, OpenJPA and EclipseLink, so multiple Java agents > (OpenJPA's, EclipseLink's) would cause trouble. > > I have no problem with plenty of other mappings in this unit testing setup. > > Where should I start looking to debug this problem? > > Best, > Laird >
NoClassDefFoundError in JavaSE environment
I'm getting an odd NoClassDefFoundError while running unit tests in a standard Java SE environment. I'm on Java 6 with OpenJPA 2.0.0-beta3. I have an AbstractType class that is a @MappedSuperclass. It is in one jar file. It contains, among other things, an @Id mapping, and a couple of straightforward @Basic/@Column mappings (no joins, no embeddables, nothing complicated). Then I have a class, RelationshipRoleTypeEntity, that extends from it. It is an @Entity and adds no additional persistent fields. The jar file and the classpath root containing my RelationshipRoleTypeEntity.class are both on the classpath. Hibernate loads and runs this fine. OpenJPA says: java.lang.NoClassDefFoundError: Could not initialize class com.jenzabar.ngp.constituent.jpa.RelationshipRoleTypeEntity at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.apache.openjpa.meta.MetaDataRepository.classForName(MetaDataRepository.java:1525) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypesInternal(MetaDataRepository.java:1501) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(MetaDataRepository.java:1479) at org.apache.openjpa.meta.MetaDataRepository.loadPersistentTypes(MetaDataRepository.java:1459) at org.apache.openjpa.jdbc.meta.MappingRepository.findBaseClassMapping(MappingRepository.java:1516) at org.apache.openjpa.jdbc.meta.MappingRepository.prepareMapping(MappingRepository.java:403) at org.apache.openjpa.meta.MetaDataRepository.preMapping(MetaDataRepository.java:736) at org.apache.openjpa.meta.MetaDataRepository.resolve(MetaDataRepository.java:625) at org.apache.openjpa.meta.MetaDataRepository.getMetaDataInternal(MetaDataRepository.java:385) at org.apache.openjpa.meta.MetaDataRepository.getMetaData(MetaDataRepository.java:358) at org.apache.openjpa.jdbc.meta.MappingRepository.getMapping(MappingRepository.java:355) at org.apache.openjpa.jdbc.meta.MappingTool.getMapping(MappingTool.java:679) at org.apache.openjpa.jdbc.meta.MappingTool.buildSchema(MappingTool.java:751) at org.apache.openjpa.jdbc.meta.MappingTool.run(MappingTool.java:649) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:149) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.synchronizeMappings(JDBCBrokerFactory.java:159) at org.apache.openjpa.jdbc.kernel.JDBCBrokerFactory.newBrokerImpl(JDBCBrokerFactory.java:117) at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:199) at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:156) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:213) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:151) at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:57) I've found that often this means that I've forgotten to put a xyz entry in my persistence.xml, but that is present as well. Other interesting bits in the log before the ultimate error: 1328 test-OpenJPA TRACE [main] openjpa.Enhance - Enhancing type "class com.jenzabar.ngp.constituent.jpa.RelationshipRoleTypeEntity" loaded by org.apache.openjpa.lib.util.temporaryclassloa...@1b4c1d7. 1735 test-OpenJPA WARN [main] openjpa.MetaData - The class "com.jenzabar.ngp.constituent.jpa.RelationshipRoleTypeEntity" listed in the openjpa.MetaDataFactory configuration property could not be loaded by sun.misc.launcher$appclassloa...@35ce36; ignoring. 1735 test-OpenJPA TRACE [main] openjpa.MetaData - java.lang.NoSuchMethodError: com.jenzabar.ngp.identity.jpa.AbstractType.pcGetManagedFieldCount()I java.lang.NoSuchMethodError: com.jenzabar.ngp.identity.jpa.AbstractType.pcGetManagedFieldCount()I I have the property openjpa.RuntimeUnenhancedClasses="supported" set because I am running in a unit test environment where I vet my mappings against Hibernate, OpenJPA and EclipseLink, so multiple Java agents (OpenJPA's, EclipseLink's) would cause trouble. I have no problem with plenty of other mappings in this unit testing setup. Where should I start looking to debug this problem? Best, Laird
Bug involving XMLSchemaSerializer and DBIdentifiers
Bug filed: https://issues.apache.org/jira/browse/OPENJPA-1540 Best, Laird
Bug in InformixDictionary: column ids come back with quotes
I'd like to confirm another bug in the InformixDictionary that cropped up
sometime between 1.2.2 and 2.0 beta.
If you ask the InformixDictionary to find a table's imported keys via its
getImportedKeys() method (
http://openjpa.apache.org/builds/latest/docs/javadoc/org/apache/openjpa/jdbc/sql/DBDictionary.html#getImportedKeys%28java.sql.DatabaseMetaData,%20org.apache.openjpa.jdbc.identifier.DBIdentifier,%20org.apache.openjpa.jdbc.identifier.DBIdentifier,%20org.apache.openjpa.jdbc.identifier.DBIdentifier,%20java.sql.Connection,%20boolean%29),
then each ForeignKey that comes back reports that its schema is, for
example:
"informix "
instead of (as I'd expect):
informix
That is, the quotes and the space padding are part of each foreign key's
getSchemaIdentifier() return value's getName() return value. This causes
all sorts of problems downstream.
Consequently, things like DBIdentifier.trimToNull() on such identifiers
don't work--since the trailing quote is actually part of the identifier, the
space padding is not trimmed.
Consequently, the SchemaGenerator tool never reports there being any foreign
keys for a table that actually has them, because its associated SchemaGroup
cannot find any Schema with a DBIdentifier whose name is:
"informix "
...when that SchemaGenerator has been asked to generate schemas from, for
example, new DBIdentifier[] { DBIdentifier.newTable("informix.foobar_table")
}.
I am not sure where the best place is to make a fix.
I will file a bug for this.
I've discovered several bugs in the reverse mapping toolchain, and have
mentioned them on this list, and have filed JIRAs for them, but haven't seen
any activity on this list or on JIRA to indicate that they've been put in or
sent to the right place. Is this the right list to report such issues?
Thanks,
Laird
XMLSchemaSerializer outputs double quotes
I'm in the process of upgrading my OpenJPA-based tools from OpenJPA 1.2.2 to 2.0. It is extremely painful and full of all sorts of backwards incompatibilities. Once I have rebuilt my code to account for the API changes (mostly in the area of DBIdentifiers), I now find that schemas are being serialized with double quotes. That is, if I hook a SchemaGenerator up to my database, and then use an XMLSchemaSerializer to process its SchemaGroup, the XML schemas that are output now contain things like this: ...where previously they contained: Consequently, any reverse mapping that takes place off of these schemas blows up. Where should I start looking to track down this problem (and file another bug report)? Thanks, Laird
Re: clone() contract broken for JDBCConfigurationImpl instances
Aha; not a show stopper: the workaround is to simply do: firstConf.setConnectionPassword(secondConf.getConnectionPassword()); firstConf.setConnection2Password(secondConf.getConnection2Password()); I'll update https://issues.apache.org/jira/browse/OPENJPA-1534 with the workaround. I also don't know what other properties don't "make it" during a clone. Laird On Wed, Feb 24, 2010 at 3:18 PM, Laird Nelson wrote: > Hello; JDBCConfigurationImpl, when cloned, drops its passwords on the > floor. > > This did not happen in version 1.2.2. > > The problem is related to the introduction of the EncryptionProvider in the > 2.0 line (and others). > > The bug is here: https://issues.apache.org/jira/browse/OPENJPA-1534 > > This is a showstopper for me, but I'm not clear what the proper resolution > is (other than to implement clone() by calling super.clone() as should be > the case). > > Thanks, > Laird >
clone() contract broken for JDBCConfigurationImpl instances
Hello; JDBCConfigurationImpl, when cloned, drops its passwords on the floor. This did not happen in version 1.2.2. The problem is related to the introduction of the EncryptionProvider in the 2.0 line (and others). The bug is here: https://issues.apache.org/jira/browse/OPENJPA-1534 This is a showstopper for me, but I'm not clear what the proper resolution is (other than to implement clone() by calling super.clone() as should be the case). Thanks, Laird
Should DBDictionary instances call Column#setAutoAssigned(true)?
I've noticed that none of the DBDictionary instances that ship with OpenJPA call Column#setAutoAssigned(true), even when it is within their power to do so. Is this by design? Does this decision logically lie elsewhere? Thanks, Laird
Datastore identity and ReverseMappingTool
I am baffled at the output of the ReverseMappingTool in OpenJPA 1.2.2 when
it comes to datastore identity.
Perhaps I am missing what datastore identity is. I had assumed that a class
conceptually has datastore identity when it has, for example, an
auto-assigned primary key. In such a case I'd expect the ReverseMapping
tool to omit any setters for this field, and to disallow its presence in
constructors.
I'd also expect the annotations produced to involve @GeneratedValue (or
whatever it is; typing from memory).
Instead I see a syntactically invalid @PrimaryKeyJoinColumn annotation
mushed into the @Table annotation, and basically nothing else (i.e. no other
mention whatsoever of the primary key column in the mapping):
@Entity
@Table(schema="foobar", name="bizbaw", @PrimaryKeyJoinColumn(name="pk",
columnDefinition="serial"))
public class Blah {
What on *earth* is happening here? As far as I can tell, this comes about
if I turn the useDatastoreIdentity property on in the reverse mapping tool.
I scanned the source base and then discovered that there's nothing in the
annotation serializer that even attempts to use @GeneratedValue. Am I on my
own for this?
Thanks,
Laird
clone() methods in the codebase--bizarre implementations?
Hi; I'm trying to understand the rationale of some of the implementations of
Cloneable in the OpenJPA codebase.
Take, for example, the clone() method in SchemaGroup.java, and its helper
methods:
public Object clone() {
SchemaGroup clone = newInstance();
clone.copy(this);
return clone;
}
/**
* Create a new instance of this class.
*/
protected SchemaGroup newInstance() {
return new SchemaGroup();
}
/**
* Copy cloneable state from the given instance.
*/
protected void copy(SchemaGroup group) {
// Method which actually does the copying
}
If clone() had been written to simply call super.clone(), there would be no
need for a newInstance() method, and, depending on the circumstances,
potentially no need for a copy method.
I suspect there was a good reason for this, but it's tripping me up in a few
places when I'm subclassing.
Does anyone know the history here? Would a set of patches be considered to
rectify this behavior and fall back on the more common super.clone()
behavior?
Best,
Laird
SchemaGenerator vs. SchemaFactory
Can someone outline for me what the difference is between these two classes (other than that SchemaGroup is a class and SchemaFactory is an interface)? To my eyes they are responsible for the same job. It also seems like a SchemaGenerator should, in all cases, be a SchemaFactory. Suppose I'm writing a database/OpenJPA-related tool. If I were looking for general-purpose connect-to-a-database-and-barf-out-a-SchemaGroup functionality, would I be better off asking someone to supply an instance of a SchemaGenerator, or an arbitrary SchemaFactory, if I were simply going to do the bare minimum in terms of calling methods? Thanks for any pointers. I know this is a vague question, but I'm looking for vague answers. :-) What I mean is, I'm mainly interested in reasons that these two classes look so similar--perhaps the mighty Abe White forgot what he had already written? Or had other ideas in mind? Best, Laird
Getting META-INF/persistence.xml read?
I'm creating a tool that uses the JDBCConfigurationImpl() class. I was under the impression that somehow this class is capable of finding the META-INF/persistence.xml file if it is present on the classpath, thus setting things like the database user name, the password, the connection url, and so forth. Despite the fact that my JUnit test case that I'm trying to make pass is running with a classpath that serves as the root for an existing META-INF/persistence.xml file, that file is never seen, and the moment I try to get JDBCConfigurationImpl to get a DataSource, everything blows up. I looked at the source code of the ReverseMappingTool's main() method to see how it does it, on the theory that maybe this was a case of cut-and-paste-development--perhaps the ReverseMappingTool, the SchemaTool, etc. all have their own way of locating this file? But I saw (a) no such code, and (b) no code anywhere inside ReverseMappingTool that tries to process the "-properties" command line argument. This leads me to believe that some other class is processing the "-properties" command line argument, and I thought that if such an argument were not present, then it would suffice to simply have a META-INF/persistence.xml on the classpath. No such luck. Any ideas? For the record, I find the whole "plugin" pseudo-dependency injection approach arcane, unreliable and confusing. Best, Laird
AnnotationPersistenceMappingSerializer question
I'm looking at the 1.3.x branch. In AnnotationPersistenceMappingSerializer.java, line 510, when the serializer begins its work of recording annotation information for columns, it does so by consulting the FieldMapping's getMappingInfo().getColumns() method. OK; fine; push that on the mental stack. But then at line 544, when the serializeColumn() method is trying to figure out (among other things) what sorts of attributes to place on a @ManyToOne annotation, it decides whether or not to output the "referencedColumnName" attribute based on one of those column's getTarget() method. But the kinds of Columns returned by MappingInfo.getColumns() will never have targets set. Consequently it looks to my naive eyes (and this matches behavior I'm also seeing) that referencedColumnName will never be output. I think instead it should be consulting the MappingInfo.getForeignKey().getPrimaryKeyColumns() method instead for this purpose, yes? I will file a JIRA for this issue, but will retract it if someone can give me a good explanation. Thanks, Laird
MappedSuperclasses?
Hello; I asked this question before and got crickets. What is the best way to customize a ReverseMappingTool run such that for every table mapped I create a MappedSuperclass that it inherits from? I am using OpenJPA 1.2.1 and generating annotations, not XML. So if I have a database table named Person, then I want a PersonMappedSuperclass.java and a Person.java class that inherits from it. I am so close it is maddening, but cannot cross the final chasm. The first thing I do is to set my ReverseCustomizer to change the incoming ClassMapping to setEmbeddedOnly(true), and rename it to xyzMappedSuperclass. Then I generate a new class, set the MappedSuperclass as its parent, and install the new mapping directly into the repository, like so (inside customize(ClassMapping)): mapping.setEmbeddedOnly(true); final Class mappingClass = mapping.getDescribedType(); final String mappingClassName = mappingClass.getName(); final String newClassName = mappingClassName.substring(0, mappingClassName.length() - "MappedSuperclass".length()); final Class newClass = this.tool.generateClass(newClassName, mappingClass); final MappingRepository mappingRepository = this.tool.getRepository(); final ClassMapping newMapping = (ClassMapping)mappingRepository.addMetaData(newClass); newMapping.setPCSuperclass(mappingClass); newMapping.setTable(mapping.getTable()); // ? maybe? newMapping.setEmbeddedOnly(false); This does more or less what I want: at the end of this run, I get a mapped superclass and an entity class that extends from it. However, none of the mapped superclass field information is filled in. That is, I get things like: @Basic Instead of @Basic @Column(name="pmt_no", length=16) Bug 1360 seems to be related to this ( http://issues.apache.org/jira/browse/OPENJPA-1360). It would appear that in the 1.2.x line, anyhow, it is impossible to create a MappedSuperclass whose field annotations are properly filled in, thus of course defeating the entire purpose of a MappedSuperclass. I would be interested to learn if ANYONE has ever generated MappedSuperclasses using this tool. Best, Laird
Question regarding -properties option of ReverseMappingTool
The documentation for ReverseMappingTool says that the -properties command line option can take a file path or a resource name. I can get this to work if I give a file path, but not if I give a resource name. Assume I'm in the C:\crap directory. If I specify this: -properties C:\crap\META-INF\openjpa.xml ...everything works. If I specify either of these with a classpath that includes the current directory: -properties META-INF/openjpa.xml -properties /META-INF/openjpa.xml -properties openjpa.xml ...the openjpa.xml file is not picked up. Is the documentation in error, or do I not fully understand what a resource name is? OpenJPA 1.2.1. Thanks, Laird
Maven dependencies in 1.3.0-SNAPSHOT
Perhaps it's just me, but I noticed that all of a sudden dependencies like commons-lang and serp are not being pulled down when I depend on openjpa (I cleaned my local repository of OpenJPA artifacts, and after rebuilding, my build fails, saying that it cannot find classes that would be present if commons-lang and serp were pulled down). Was a change made? I noticed that in the openjpa POM they are listed as provided, which indicates they should be present, yes? Best, Laird
ReverseMappingTool: easiest way to produce @MappedSuperclasses?
Where in the customize(ClassMapping) method of ReverseCustomizer would I set something that would let the code generators downstream know that they should generate mapped superclasses instead of entities? Would I install a different ClassStrategy on the mapping? Thanks, Laird
Re: Deducing a primary key, customizing in ReverseCustomizer?
On Thu, Oct 22, 2009 at 10:33 AM, Laird Nelson wrote: > Before I begin the long, slow process of understanding these hundreds of > methods, does anyone know if at customize(FieldMapping)-time I have access > to: > * The names of unique indices found so far (I presume yes) > * The ability to "step in" and inform the ReverseMappingTool that the field > mapping under consideration is to be output as a primary key, even though > that information was not present in the database > > ...? If I don't have these abilities, then this is the wrong path to go > down. > OK, got it working. For those who care: The ReverseMappingTool does not actually let your ReverseCustomizer decide a table's table type if it detects that the table does not have a primary key. So even if your customizer is written to tell the system, hey, this table is a base table, and even if it's written to install a PrimaryKey onto that table, that method will never be called. Instead, in the setTool() method, I got all the tables, iterated through them one at a time, installed my inferred PrimaryKeys (marking each as logical), and then returned--sure enough, my customizer is now called by the tool as though these tables actually did in fact have primary key information. Thanks, Laird
Deducing a primary key, customizing in ReverseCustomizer?
Before I spend a lot of time going down the wrong path, I thought I'd ask the (rather silent these days?) users list what the best approach is. I work for a company that has a 30 year old database that chose for all sorts of reasons to have many of its tables defined without primary keys. Of any kind. What such tables *do* have are unique indices. For the sake of this argument, assume that for various valid and invalid reasons we cannot go back and add true primary keys. I am actually working on seeing if this is possible--it's quite obviously the most appropriate solution. But, failing that, a human being can glance at the DDL for these tables, and, being familiar with some naming conventions, can determine which of potentially many unique indices is the "real" one that is treated by the rest of the application as that table's primary key. My challenge is to see if I can perform the same analysis from within the bowels of an OpenJPA ReverseCustomizer and so cause the ReverseMappingTool to spit out JPA entities with @Id annotations, even in the case where the tool, unassisted, could not discover any primary key information. My initial thought was to perform this analysis within the customize(FieldMapping) method. Then I saw the Javadoc for FieldMapping and realized it had somewhere around 100 methods (by inheritance). Egad. Before I begin the long, slow process of understanding these hundreds of methods, does anyone know if at customize(FieldMapping)-time I have access to: * The names of unique indices found so far (I presume yes) * The ability to "step in" and inform the ReverseMappingTool that the field mapping under consideration is to be output as a primary key, even though that information was not present in the database ...? If I don't have these abilities, then this is the wrong path to go down. Thank you, Laird
ReverseMappingTool: can I turn off the generation of orm.xml?
I was unable to figure out from the documentation here () how to turn off the generation of the orm.xml file. I don't actually care, but there seems to be a bug in the tool. If I run the mapper twice, it appears that the orm.xml file's being present on the second run causes the tool to crash. I'll detail this in another email, but, quite frankly, I would prefer to use annotations anyhow. Any help gratefully appreciated. Best, Laird
ReverseCustomizer question
Is it possible to have a ReverseCustomizer generate two classes? Specifically, for my day job this time, I'm required to generate a @MappedSuperclass and an empty JPA entity skeleton that extends it. I would love it if we could make use of an existing tool--like OpenJPA's ReverseMappingTool--to do this for us. But I don't see an easy way for the ReverseCustomizer to indicate that it's going to generate a MappedSuperclass and an Entity class as part of the same table-to-Java operation. Any help is appreciated. Best, Laird
Re: Cascading problem...bug?
I have altered the Maven project locally to use Hibernate instead and it
runs the test case with no problems in exactly the way that I would expect.
I'll try it with EclipseLink next. If that succeeds as well, I'll file a
bug.
Best,
Laird
On Sat, Oct 3, 2009 at 1:03 PM, Laird Nelson wrote:
> I've attached a simple maven project that demonstrates what might be a bug
> in the way that OpenJPA handles cascading. However I freely admit of the
> strong possibility that instead I'm just being stupid. That's why I'm
> coming to the user list first.
>
> Please find attached a JPA project that describes the following:
>
> X has zero to many XYs indexed by their type and an autogenerated ID. X's
> @OneToMany relationship with XY is marked as CascadeType.ALL.
>
> Y has exactly one X and an autogenerated ID. Y's @ManyToOne relationship
> with X is marked as CascadeType.ALL.
>
> XY has exactly one X
> XY has exactly one Y
> XY has a type attribute
> XY is uniquely identified logically by its X and type
>
> In the project, I do this:
> X x = new X();
> Y y = new Y(x);
> x.put("TestType", y); // causes new XY to be put in the JPA @OneToMany Map
> association
> this.em.persist(x);
>
> It fails, telling me that it has encountered an unpersisted object in the
> XY map. It suggests as a solution that I should mark the XY map as being
> CascadeType.PERSIST, which I have (?!).
>
> I've modified the test case to make things very explicit as well; I have
> inserted persist() and flush() calls liberally throughout to no effect.
>
> Thanks for your time. Unjar the attached Jar file to see the maven
> project; run with mvn test.
>
> Best,
> Laird
>
Cascading problem...bug?
I've attached a simple maven project that demonstrates what might be a bug
in the way that OpenJPA handles cascading. However I freely admit of the
strong possibility that instead I'm just being stupid. That's why I'm
coming to the user list first.
Please find attached a JPA project that describes the following:
X has zero to many XYs indexed by their type and an autogenerated ID. X's
@OneToMany relationship with XY is marked as CascadeType.ALL.
Y has exactly one X and an autogenerated ID. Y's @ManyToOne relationship
with X is marked as CascadeType.ALL.
XY has exactly one X
XY has exactly one Y
XY has a type attribute
XY is uniquely identified logically by its X and type
In the project, I do this:
X x = new X();
Y y = new Y(x);
x.put("TestType", y); // causes new XY to be put in the JPA @OneToMany Map
association
this.em.persist(x);
It fails, telling me that it has encountered an unpersisted object in the XY
map. It suggests as a solution that I should mark the XY map as being
CascadeType.PERSIST, which I have (?!).
I've modified the test case to make things very explicit as well; I have
inserted persist() and flush() calls liberally throughout to no effect.
Thanks for your time. Unjar the attached Jar file to see the maven project;
run with mvn test.
Best,
Laird
bug.jar
Description: application/java-archive
Cascade and persist issues
On a field marked @OneToMany(/*...*/ cascade = CascadeType.ALL), I am getting this error at persist() time: org.apache.openjpa.persistence.ArgumentException: Encountered new object in persistent field "blox.party.jpa.PartyEntity.postalAddresses" during attach. However, this field does not allow cascade attach. Set the cascade attribute for this field to CascadeType.MERGE or CascadeType.ALL (JPA annotations) or "merge" or "all" (JPA orm.xml). You cannot attach a reference to a new object without cascading. I am following the advice of http://www.screaming-penguin.com/node/7513 in terms of structure. To be specific, I have a Party identified with an autogenerated int PK with a @OneToMany relationship with a PartyPostalAddressBinding, which has a @ManyToOne relationship with a PostalAddress. A PostalAddress, in turn, is owned by exactly one Party. In my test case, I persist the Party (then I have to flush(), which is tremendously irritating) yielding, let's say, party1. Then I create a new PostalAddress and assign party1 as its owner. I persist that (and again have to flush() in order to avoid errors--no idea why), yielding postalAddress1. Finally, I insert a new binding that links party1 and postalAddress1 into party1's Map of bindings. I then merge() party1 (which I don't think I should have to do). It is at this point that OpenJPA tells me that my @OneToMany field, with cascade markings all over it, needs to be, um, marked with CascadeType.ALL, which it is. I am quite happy to attach all of this, but wanted to see if I'm doing something obviously stupid first. Thanks, Laird
Mapping question regarding @SecondaryTable
I have a legacy mapping question.
I have a table called id_rec (this is from a 30 year old database). It
stores, basically, a row for just about every single thing in the system.
I have another table called profile_rec. It stores, roughly, person-related
data, and has a foreign key back to the id_rec table.
All things being equal, I'd like to map these to a single object. Let's
call it Person. I'd like to annotate this like this (partially, and from
memory):
@Entity
@Table(name = "id_rec")
@SecondaryTable(name = "profile_rec", pkJoinColumns =
@PrimaryKeyJoinColumn(name = "id"))
public class Person {
//...
}
Now, I'm assuming that if I do this, and I persist() a Person, I will get a
new row in the id_rec table and the profile_rec table.
"But wait," some of you are thinking--and exactly, I foresee a wrinkle
here. What if--this is hypothetical for this example, but realistic for
other similar ones--what if a row already exists in the id_rec table with,
say, a pk of 5, and I insert a new Person whose primary key ("id") is set to
5? Is OpenJPA smart enough to realize that it should do an "upsert" on the
id_rec table? Or will it try, blindly, to slam two INSERTS home, thus
causing the transaction to roll back?
Expanding this example out a bit, I'm looking for a convenient way to map
what are effectively roles within this ancient database into a simple Java
API. I realize that I could of course make a Person have a @OneToOne
relationship with an ID/Party/Thing, but I really don't want to have the
Thing (id_rec) be something that is composed inside another object. That
is, I want any given role (account holder, student, train engineer,
whatever) to simply include his "base" information from the (related) id_rec
record. This looks exactly like what @SecondaryTable is intended for,
PROVIDED that when you're "attaching" a new role record to an *existing *base
information record the provider is smart enough to do an UPDATE on the
id_rec table, not an INSERT.
I hope I've been articulate enough to explain my problem.
Thanks,
Laird
insertable/updatable = false question
I have an entity, E2, that contains a many-to-one relationship with E1 like this: // assume E1's primary key column is x @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "x", referencedColumnName = "x", insertable = false, updatable = false) private E1 e1; Then in E2 I also have a field like this: @Column(name = "x") private int x; When I first create an instance of E2, I set x to, say, 5. Let's assume we know that E1 exists in the database under a primary key of x = 5 as well. If I examine the unpersisted/transient E2 instance, I can see that x indeed is 5, and e1 is null, as I'd expect. Now--we're on the server side for all this--I do this: e2 = this.em.merge(e2); this.em.flush(); After the flush, I would expect that: e2 would be persisted e2 would have its x = 5 (unchanged) e2.e1 would be NON NULL. That is if I did: e2.getE1(); I'd get back a non-null return value. But instead I am seeing that e2.e1 is null. Is this expected behavior? What I'm looking for is the ability for someone to create an E2 without an E1 in hand, pass it in to my EJB method, where I will--using lazy loading--"inflate" the E1 relationship. I can't figure out how to make this happen. Thanks, Laird
OPENJPA-1001
Hello, I'm encountering this bug, but with a different stack than the one reported in https://cwiki.apache.org/jira/browse/OPENJPA-1001. I'm using OpenJPA 1.3.0-SNAPSHOT and am accessing it through OpenEJB. I will attempt to reproduce this bug with a simpler test case than the one I'm currently running, but felt that given the priority of the bug I'd report what I could at the moment. Here is a snippet of the stack: Caused by: org.apache.openjpa.persistence.PersistenceException: Index: 3, Size: 3 at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:877) at org.apache.openjpa.kernel.BrokerImpl.find(BrokerImpl.java:776) at org.apache.openjpa.kernel.BrokerImpl.isDetached(BrokerImpl.java:4289) at org.apache.openjpa.kernel.VersionAttachStrategy.attach(VersionAttachStrategy.java:78) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:251) at org.apache.openjpa.kernel.AttachManager.attach(AttachManager.java:104) at org.apache.openjpa.kernel.BrokerImpl.attach(BrokerImpl.java:3215) at org.apache.openjpa.kernel.DelegatingBroker.attach(DelegatingBroker.java:1158) at org.apache.openjpa.persistence.EntityManagerImpl.merge(EntityManagerImpl.java:769) at org.apache.openejb.persistence.JtaEntityManager.merge(JtaEntityManager.java:102) This results from a simple merge() call on an entity that has not been persisted before. Looking through the stack, perhaps it is also relevant that my entities at the moment do not have @Version fields. I hope this helps someone out in rooting around to get to the bottom of it; this is kind of blocking me--is there a workaround? Thanks, Laird
Odd use case
Hello, folks; OpenJPA has impressed me so far for thinking in most cases
waaay ahead of the curve. I'm hoping that perhaps this use case is handled
natively.
I am mapping a 30-year-old relational schema by hand (since it has no
foreign key or primary key information).
One of the cases I've run across is a Document object (doc_table) that has a
logical @ManyToMany relationship with a GLAccount (gla_rec).
Now, obviously I know how to mark such a thing up in JPA. But here's the
wrinkle.
In the database, there is no join table. Instead, the doc_table has 4/5 of
what would be needed for a true foreign key back to the gla_rec table (a
gla_rec is identified by five primary keys). The fifth component is a
fiscal year, which in the old application the user always has in hand.
Using straight JPA, I have no choice: I will have to annotate all four
columns in the doc_table as being just simple old String fields, and then I
will just have to know internally that when I want to trace back the
relationship to a GLAccount, I need to run a query with an entity manager,
supplying the fiscal year to the WHERE clause. This is tedious and
annoying.
What I'd LIKE to do is somehow have it so that I can designate a @Transient
property (or maybe some other bit of information) on the Document class as
being that fifth component.
So, for example, I might notate things like this (this is all hypothetical):
@Transient
private int fiscalYear;
@ManyToOne
@JoinColumns({
@JoinColumn(name = "glapk1", /* ... and so on ... */),
/* ...and so on for the other three ... */
})
@some.annotation.here.AdditionalJoinInfo(field = "fiscalYear",
referencedColumnName = "fscl_yr")
The idea is that we augment the @JoinColumns information--or replace it, or
something--in such a way that the remaining property necessary to make this
a true @ManyToOne relationship is supplied by looking up its value in an
otherwise @Transient property. It has the effect of supplying a parameter
to a where clause automatically, which means that I could then simply have
an accessor called getGeneralLedgerAccount(), which, if the fiscalYear
property was set, would return me exactly one (or zero, I suppose). If the
fiscalYear property was NOT set, it would return me null. No queries to
write; just straight old relationship navigation.
I am seeing this all over the schemas and am wondering if this was some sort
of odd pattern that used to be followed back in the day. Anyhow, I was
given hope too by reading the javadocs of the Joinable class in OpenJPA,
which says, in part, "This allows us to support joins to only some of the
columns of a mapping" This made me hope that maybe someone has already
thought of something similar.
Thanks,
Laird
Define index?
Is it possible to define a non-unique index in OpenJPA? Hibernate offers the @Index annotation to do this as part of its DDL generation machinery. My apologies if this was mentioned; I didn't see it in http://openjpa.apache.org/builds/latest/docs/manual/manual.html. Thanks, Laird
JoinColumn: match its length to the referenced column?
One more bug confirmation for today: when generating DDL, I am noticing that OpenJPA does not match the length or type of a JoinColumn to its referenced column. That is, suppose the referenced column is defined like this: @Column(name = "title", length = 4, columnDefinition = "CHAR(4)") ...and in another class the JoinColumn is defined like this: @JoinColumn(name = "title", referencedColumnName = "title") When I run the DDL machinery in OpenJPA, the first column is correctly defined as being a CHAR(4). But the foreign key column is defined as being VARCHAR(255). EclipseLink handles this the way I would expect; I haven't tried Hibernate. Should I file a JIRA on this? Thanks, Laird
Bug confirmation? Cannot have more than one unique column
I wanted to confirm this bug here before I recorded it. If I have two columns in my entity that are both marked @Column( ... unique = true), then the DDL generation machinery of OpenJPA attempts to create two unique constraints, one for each column--so far so good--but with the same constraint name of _UNQ. The H2 database, at least, does not permit two unique constraints to have the same identifier. Can someone confirm that this is a bug, and, if so, I will enter it into JIRA. Thanks, Laird
Need to list embeddable classes in persistence.xml?
Hello. I've found that OpenJPA needs me to list my @Embeddable classes in persistence.xml as well as my @Entity classes. This is not needed by Hibernate or EclipseLink. I couldn't find a relevant section of the specification that addresses this. Is this a bug or just a minor annoyance? I'm trying to code for maximum portability between at least these three persistence providers and so want to know where the edge cases are. I'm using OpenJPA-1.3.0-SNAPSHOT from the Apache snapshots Maven repository. Thanks, Laird
Re: OPENJPA_SEQUENCE_TABLE: needed even with IDENTITY columns?
On Sun, Apr 19, 2009 at 3:41 AM, Paul Copeland (via Nabble) < ml-user+196740-2043936...@n2.nabble.com > wrote: > I noticed that |GenerationType.SEQUENCE also uses that table (with > Postgres provider). Maybe you have one of those on some Entity.| > Nope; I sure do not. :-( Best, Laird
