Nabble - OpenJPA

Query problem with open jpa 1.0.2

2008-07-08T15:30:41Z

Hi, I'm working on a project using openjpa 1.0.2. I got
org.apache.openjpa.persistence.ArgumentException while executing a simple
query today, wish someone can help me on this issue. Thanks

The query I'm trying to execute is:
"select job from job j"
Moreover there is no problem for me to create a new job record.

Three related persistence classes are defined as the following:

@Table(name = "job")
@Entity(name = "job")
public class Job implements Serializable{
@Id
@Column (name = "job_id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long jobId;

@Column (name = "job_name", length = 255, nullable = false)
private String jobName;

@Column
private String status;

@ManyToOne (optional = false)
@JoinColumn(name = "create_by", referencedColumnName = "user_id")
private User createUser;

@Column (name = "create_time")
private Date createTime;

@ManyToOne (optional = true)
@JoinColumn(name = "update_by", referencedColumnName = "user_id")
private User updateUser;

@Column (name = "update_time")
private Date updateTime;

@ManyToOne (optional = false, fetch = FetchType.EAGER)
@JoinColumn(name = "proj_lead_id", referencedColumnName = "user_id")
private User projectLead;

@ManyToOne (optional = false, fetch = FetchType.EAGER)
@JoinColumn(name = "designer_id", referencedColumnName = "user_id")
private User designer;

@Column (name = "approve_by")
private String approveBy;

@Column (name = "concept_date")
private Date conceptDate;

@Column (name = "vendor_due_date")
private Date vendorDueDate;

@Column (name = "release_date")
private Date releaseDate;
...
}

@Entity(name = "user")
@Table(name = "usr_user")
public class User implements Serializable {

private static final long serialVersionUID = 3L;

@Id
@Column (name = "user_id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long userId;

@Column
private String password;

@Column (name = "user_name", length = 20, nullable = false)
private String userName;

@Column (name = "first_name", length = 32, nullable = false)
private String firstName;

@Column (name = "last_name", length = 32, nullable = false)
private String lastName;

@Column (name = "mid_name", length = 20, nullable = true)
private String midName;

@ManyToOne (optional = false, fetch = FetchType.EAGER)
@JoinColumn(name = "role_id", referencedColumnName = "role_id")
private Role role;

...
}

@Entity (name = "role")
@Table(name = "role")
public class Role {
@Id
@Column (name="role_id")
@GeneratedValue(strategy = GenerationType.IDENTITY)
private long roleId;

@Column (name="role_name", length = 20, nullable = false)
private String roleName;
...
}

and the exception details I got are
javax.faces.FacesException: Error calling action method of component with id
job-search-form:search-button
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:69)
at javax.faces.component.UICommand.broadcast(UICommand.java:121)
at javax.faces.component.UIViewRoot._broadcastForPhase(UIViewRoot.java:292)
at javax.faces.component.UIViewRoot.process(UIViewRoot.java:209)
at javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:117)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:32)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:103)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:76)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:148)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.myfaces.webapp.filter.ExtensionsFilter.doFilter(ExtensionsFilter.java:147)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:595)
Caused by: javax.faces.el.EvaluationException: javax.el.ELException:
/web/searchJob.xhtml @278,43 action="#{jobBacking.search}":
org.springframework.dao.InvalidDataAccessApiUsageException: nested exception
is <openjpa-1.0.2-r420667:627158 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: null
at
javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:79)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:54)
... 23 more
Caused by: javax.el.ELException: /web/searchJob.xhtml @278,43
action="#{jobBacking.search}":
org.springframework.dao.InvalidDataAccessApiUsageException: nested exception
is <openjpa-1.0.2-r420667:627158 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: null
at
com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:74)
at
javax.faces.component._MethodExpressionToMethodBinding.invoke(_MethodExpressionToMethodBinding.java:75)
... 24 more
Caused by: org.springframework.dao.InvalidDataAccessApiUsageException:
nested exception is <openjpa-1.0.2-r420667:627158 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: null
at
org.springframework.orm.jpa.EntityManagerFactoryUtils.convertJpaAccessExceptionIfPossible(EntityManagerFactoryUtils.java:269)
at
org.springframework.orm.jpa.DefaultJpaDialect.translateExceptionIfPossible(DefaultJpaDialect.java:120)
at
org.springframework.dao.support.DataAccessUtils.translateIfNecessary(DataAccessUtils.java:212)
at
org.springframework.orm.jpa.JpaAccessor.translateIfNecessary(JpaAccessor.java:152)
at org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:190)
at
org.springframework.orm.jpa.JpaTemplate.executeFind(JpaTemplate.java:152)
at org.springframework.orm.jpa.JpaTemplate.find(JpaTemplate.java:299)
at org.springframework.orm.jpa.JpaTemplate.find(JpaTemplate.java:295)
at com.xyz.dao.JobDAO.searchJob(JobDAO.java:209)
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:585)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:301)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:198)
at $Proxy11.searchJob(Unknown Source)
at com.xyz.backing.JobBacking.search(JobBacking.java:157)
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:585)
at org.apache.el.parser.AstValue.invoke(AstValue.java:152)
at org.apache.el.MethodExpressionImpl.invoke(MethodExpressionImpl.java:276)
at
com.sun.facelets.el.TagMethodExpression.invoke(TagMethodExpression.java:68)
... 25 more
Caused by: <openjpa-1.0.2-r420667:627158 nonfatal user error>
org.apache.openjpa.persistence.ArgumentException: null
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:808)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:769)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:765)
at
org.apache.openjpa.kernel.DelegatingQuery.execute(DelegatingQuery.java:517)
at org.apache.openjpa.persistence.QueryImpl.execute(QueryImpl.java:238)
at
org.apache.openjpa.persistence.QueryImpl.getResultList(QueryImpl.java:277)
at org.springframework.orm.jpa.JpaTemplate$9.doInJpa(JpaTemplate.java:307)
at org.springframework.orm.jpa.JpaTemplate.execute(JpaTemplate.java:185)
... 44 more
Caused by: java.lang.NullPointerException
at org.apache.openjpa.jdbc.kernel.exps.PCPath.initialize(PCPath.java:445)
at
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.initialize(SelectConstructor.java:197)
at
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.newSelect(SelectConstructor.java:119)
at
org.apache.openjpa.jdbc.kernel.exps.SelectConstructor.evaluate(SelectConstructor.java:73)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.createWhereSelects(JDBCStoreQuery.java:331)
at
org.apache.openjpa.jdbc.kernel.JDBCStoreQuery.executeQuery(JDBCStoreQuery.java:171)
at
org.apache.openjpa.kernel.ExpressionStoreQuery$DataStoreExecutor.executeQuery(ExpressionStoreQuery.java:676)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:988)
at org.apache.openjpa.kernel.QueryImpl.execute(QueryImpl.java:799)
... 51 more
--
View this message in context: http://n2.nabble.com/Query-problem-with-open-jpa-1.0.2-tp395802p395802.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

From forum: OpenJPA Users

Tomcat Injection

2008-07-08T13:02:06Z

Hello,

After reading some documentation, I though I had my injection code worked
out, but apparently not.

I am using Tomcat with OpenJPA.

In my class, I have:
@PersistenceUnit(unitName = "CallScheduler")
private @Resource(name="bean/OpenJPAEMF")OpenJPAEntityManagerFactory emf;
In my META-INF/context.xml, I have:
<Resource name="bean/OpenJPAEMF" auth="Container"
factory="org.apache.openjpa.persistence.OpenJPAEntityManagerFactory"
type="org.apache.openjpa.persistence.OpenJPAEntityManagerFactory.class" />

While executing a method in my class, emf is still null.

How should I instantiate emf? I am under the impression that
OpenJPAPersistence.createEntityManagerFactory is for unmanaged code...

Eric
--
View this message in context: http://n2.nabble.com/Tomcat-Injection-tp395699p395699.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

From forum: OpenJPA Users

Error while merging object tree

2008-07-08T05:47:30Z

Hi,

I get following error while merging a persisted entity A after adding new child entities to it. The following relation exists between entities: A -> (many to many) B -> (one to many) C.

The issue is I don't get this error while using openjpa 1.0.0, but I get it using openjpa 1.1.0. If I add "cascade= {CascadeType.MERGE, CascadeType.PERSIST}" to ChainEntityC.chainEntityB field It works with openjpa 1.1.0 but this time I have problems with openjpa 1.0.0.

I'm not sure if this is a bug or an older bug is fixed. Do we need to open a jira for this or not? My opinion is the cascade type on entity C should not be necessary because C is the last entity in the chain and should be cascaded from A to C. Cascade from C to B does not sound logical.

The test code is attached and works if you copy it to openjpa-persistence-jdbc test module.

Thanks.

Ekin Sokmen.

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.938 sec <<< FAILURE!
testChainUpdate(org.apache.openjpa.persistence.relations.TestChainEntities) Time elapsed: 2.85 sec <<< ERROR!
<openjpa-1.1.0-r422266:659716 nonfatal user error> org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged object in persistent field "org.apache.openjpa.persistence.relations.ChainEntityC.chainEntityB" during flush. However, this field does not allow cascade persist. Set the cascade attribute for this field to CascadeType.PERSIST or CascadeType.ALL (JPA annotations) or "persist" or "all" (JPA orm.xml), or enable cascade-persist globally, or manually persist the related field value prior to flushing. You cannot flush unmanaged objects or graphs that have persistent associations to unmanaged objects.
FailedObject: org.apache.openjpa.persistence.relations.ChainEntityB@1702c48
        at org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:753)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:594)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478)
        at org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2819)
        at org.apache.openjpa.kernel.PNewProvisionalState.nonprovisional(PNewProvisionalState.java:44)
        at org.apache.openjpa.kernel.StateManagerImpl.nonprovisional(StateManagerImpl.java:1130)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:772)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlushPCs(SingleFieldManager.java:735)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:637)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478)
        at org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2819)
        at org.apache.openjpa.kernel.PNewProvisionalState.nonprovisional(PNewProvisionalState.java:44)
        at org.apache.openjpa.kernel.StateManagerImpl.nonprovisional(StateManagerImpl.java:1130)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:772)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlushPCs(SingleFieldManager.java:735)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:637)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562)
        at org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478)
        at org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2819)
        at org.apache.openjpa.kernel.PDirtyState.beforeFlush(PDirtyState.java:37)
        at org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:957)
        at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1945)
        at org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1905)
        at org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1823)
        at org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
        at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1347)
        at org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:877)
        at org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:512)
        at org.apache.openjpa.persistence.relations.TestChainEntities.testChainUpdate(TestChainEntities.java:46)
        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:585)
        at junit.framework.TestCase.runTest(TestCase.java:154)
        at junit.framework.TestCase.runBare(TestCase.java:127)
        at junit.framework.TestResult$1.protect(TestResult.java:106)
        at junit.framework.TestResult.runProtected(TestResult.java:124)
        at junit.framework.TestResult.run(TestResult.java:109)
        at junit.framework.TestCase.run(TestCase.java:118)
        at org.apache.openjpa.persistence.test.PersistenceTestCase.run(PersistenceTestCase.java:122)
        at junit.framework.TestSuite.runTest(TestSuite.java:208)
        at junit.framework.TestSuite.run(TestSuite.java:203)
        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:585)
        at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
        at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
        at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
        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:585)
        at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:334)
        at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:980)

test_case.zip (3K) Download Attachment

From forum: OpenJPA Users

[jira] Created: (OPENJPA-654) Missing dictionary properties in OpenJPA docs

2008-07-08T05:40:31Z

Missing dictionary properties in OpenJPA docs
---------------------------------------------

Key: OPENJPA-654
URL: https://issues.apache.org/jira/browse/OPENJPA-654
Project: OpenJPA
Issue Type: Bug
Components: docs
Affects Versions: 1.1.0
Reporter: David Ezzio

The following properties are found in DBDictionary.java, but are not (unlike most) documented in the User's Guide, section "4.4.1. DBDictionary Properties":

allowsAliasInBulkClause
batchLimit
bitLengthFunction
booleanTypeName
castFunction
closePoolSQL
concatenateDelimiter
concatenateFunction
currentDateFunction
currentTimeFunction
currentTimestampFunction
datePrecision
dropTableSQL
fixedSizeTypeNames
getStringVal
inClauseLimit
maxEmbeddedBlobSize
maxEmbeddedClobSize
platform
rangePosition
requiresCastForComparisons
requiresCastForMathFunctions
requiresTargetForDelete
searchStringEscape
sequenceNameSQL
sequenceSQL
sequenceSchemaSQL
supportsAutoAssign
supportsCascadeUpdateAction
supportsComments
supportsCorrelatedSubselect
supportsDefaultUpdateAction
supportsModOperator
supportsNullUpdateAction
supportsRestrictUpdateAction
supportsXMLColumn
trimBothFunction
trimLeadingFunction
trimTrailingFunction
xmlTypeName

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: OpenJPA Developers

Error while merging object three

2008-07-08T05:35:44Z

Hi,

I get following error while merging a persisted entity A after adding new
child entities to it. The following relation exists between entities: A ->
(many to many) B -> (one to many) C.

The issue is I don't get this error while using openjpa 1.0.0, but I get it
using openjpa 1.1.0. If I add "cascade= {CascadeType.MERGE,
CascadeType.PERSIST}" to ChainEntityC.chainEntityB field It works with
openjpa 1.1.0 but this time I have problems with openjpa 1.0.0.

I'm not sure if this is a bug or an older bug is fixed. Do we need to open a
jira for this or not? My opinion is the cascade type on entity C should not
be necessary because C is the last entity in the chain and should be
cascaded from A to C. Cascade from C to B does not sound logical.

The test code is attached and works if you copy it to
openjpa-persistence-jdbc test module.

Thanks.

Ekin Sokmen.

Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 2.938 sec
<<< FAILURE!
testChainUpdate(org.apache.openjpa.persistence.relations.TestChainEntities)
Time elapsed: 2.85 sec <<< ERROR!
<openjpa-1.1.0-r422266:659716 nonfatal user error>
org.apache.openjpa.persistence.InvalidStateException: Encountered unmanaged
object in persistent field
"org.apache.openjpa.persistence.relations.ChainEntityC.chainEntityB" during
flush. However, this field does not allow cascade persist. Set the cascade
attribute for this field to CascadeType.PERSIST or CascadeType.ALL (JPA
annotations) or "persist" or "all" (JPA orm.xml), or enable cascade-persist
globally, or manually persist the related field value prior to flushing. You
cannot flush unmanaged objects or graphs that have persistent associations
to unmanaged objects.
FailedObject: org.apache.openjpa.persistence.relations.ChainEntityB@1702c48
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:753)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:594)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2819)
at
org.apache.openjpa.kernel.PNewProvisionalState.nonprovisional(PNewProvisionalState.java:44)
at
org.apache.openjpa.kernel.StateManagerImpl.nonprovisional(StateManagerImpl.java:1130)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:772)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPCs(SingleFieldManager.java:735)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:637)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2819)
at
org.apache.openjpa.kernel.PNewProvisionalState.nonprovisional(PNewProvisionalState.java:44)
at
org.apache.openjpa.kernel.StateManagerImpl.nonprovisional(StateManagerImpl.java:1130)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPC(SingleFieldManager.java:772)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlushPCs(SingleFieldManager.java:735)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:637)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:562)
at
org.apache.openjpa.kernel.SingleFieldManager.preFlush(SingleFieldManager.java:478)
at
org.apache.openjpa.kernel.StateManagerImpl.preFlush(StateManagerImpl.java:2819)
at
org.apache.openjpa.kernel.PDirtyState.beforeFlush(PDirtyState.java:37)
at
org.apache.openjpa.kernel.StateManagerImpl.beforeFlush(StateManagerImpl.java:957)
at org.apache.openjpa.kernel.BrokerImpl.flush(BrokerImpl.java:1945)
at
org.apache.openjpa.kernel.BrokerImpl.flushSafe(BrokerImpl.java:1905)
at
org.apache.openjpa.kernel.BrokerImpl.beforeCompletion(BrokerImpl.java:1823)
at
org.apache.openjpa.kernel.LocalManagedRuntime.commit(LocalManagedRuntime.java:81)
at org.apache.openjpa.kernel.BrokerImpl.commit(BrokerImpl.java:1347)
at
org.apache.openjpa.kernel.DelegatingBroker.commit(DelegatingBroker.java:877)
at
org.apache.openjpa.persistence.EntityManagerImpl.commit(EntityManagerImpl.java:512)
at
org.apache.openjpa.persistence.relations.TestChainEntities.testChainUpdate(TestChainEntities.java:46)
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:585)
at junit.framework.TestCase.runTest(TestCase.java:154)
at junit.framework.TestCase.runBare(TestCase.java:127)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:118)
at
org.apache.openjpa.persistence.test.PersistenceTestCase.run(PersistenceTestCase.java:122)
at junit.framework.TestSuite.runTest(TestSuite.java:208)
at junit.framework.TestSuite.run(TestSuite.java:203)
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:585)
at
org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:585)
at
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:334)
at
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:980)

From forum: OpenJPA Users

EAGER vs. LAZY loading - weird behaviour in OpenJPA 1.0.1

2008-07-08T04:56:36Z

Hi
I refactored my source code quoted in
http://n2.nabble.com/Incredible-set-of-statements-td221053.html
Currently I use:

@Entity
public class Customer {
...
@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy =
"customer")
private Set<Product> products = new HashSet<Product>();
...
}

@Entity
public class Product {
...
@ManyToOne(cascade = { CascadeType.MERGE, CascadeType.REFRESH }, fetch =
FetchType.EAGER)
@JoinColumn(name = "billacc_id", nullable = false)
Customer customer;

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy
= "product")
@OrderBy(value = "created DESC")
private List<RequestLog> logs = new ArrayList<RequestLog>();
...
}

@Entity
public class RequestLog {
...
@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.LAZY)
@JoinColumn(name = "product_id", nullable = false)
private Product product;

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy =
"request")
@OrderBy(value = "created DESC")
private List<ResponseLog> children = new ArrayList<ResponseLog>();
...
}

@Entity
public class ResponseLog {
...
@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.LAZY)
@JoinColumn(name = "request_id", nullable = false)
private RequestLog request;
...
}

I've noticed 2 cases of outlandish manner.

1) When I use finder for Customer or Product (with RequestLog.product using
fetchType == LAZY) I got initialized structure with all RequestLogs'
references to Products set to null

2) When I use finder for Customer or Product (with RequestLog.product using
getchType == EAGER) I see that OpenJPA generate queries to get Customer,
Product, RequestLog from DB, but queries for RequestLogs are joins using all
classes from bottom to up - (request_log, product and customer) despite the
fact, that EM has gathered these data in previous queries and could use it
instead of redundant selecting them from DB.

Is it usual OpenJPA behaviour?

-----
thanks, Beniamin
My homesite - http://www.mazan.pl http://www.mazan.pl
--
View this message in context: http://n2.nabble.com/EAGER-vs.-LAZY-loading---weird-behaviour-in-OpenJPA-1.0.1-tp364201p364201.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

thanks
Beniamin

From forum: OpenJPA Users

svn commit: r674609 - /openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/datacache/QueryCacheStoreQuery.java

2008-07-07T12:41:33Z

Author: allee8285
Date: Mon Jul 7 12:41:32 2008
New Revision: 674609

URL: http://svn.apache.org/viewvc?rev=674609&view=rev
Log:
OPENJPA-653 - Commit for Jeremy Bauer

Modified:
openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/datacache/QueryCacheStoreQuery.java

Modified: openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/datacache/QueryCacheStoreQuery.java
URL: http://svn.apache.org/viewvc/openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/datacache/QueryCacheStoreQuery.java?rev=674609&r1=674608&r2=674609&view=diff
==============================================================================
--- openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/datacache/QueryCacheStoreQuery.java (original)
+++ openjpa/trunk/openjpa-kernel/src/main/java/org/apache/openjpa/datacache/QueryCacheStoreQuery.java Mon Jul 7 12:41:32 2008
@@ -569,7 +569,10 @@
try {
// make sure we didn't abort
if (_maintainCache) {
- QueryResult res = new QueryResult(_qk, _data.values());
+ QueryResult res = null;
+ synchronized (this) {
+ res = new QueryResult(_qk, _data.values());
+ }
_cache.put(_qk, res);
abortCaching();
}

From forum: OpenJPA Commits

HuyAnh Ngo is out of the office.

2008-07-07T09:27:49Z

I will be out of the office starting 07/07/2008 and will not return until
07/14/2008.

I will respond to your message when I return.

From forum: OpenJPA Developers

[jira] Created: (OPENJPA-653) Concurrency issue with query cache enabled

2008-07-07T07:15:31Z

Concurrency issue with query cache enabled
------------------------------------------

Key: OPENJPA-653
URL: https://issues.apache.org/jira/browse/OPENJPA-653
Project: OpenJPA
Issue Type: Bug
Components: datacache
Affects Versions: 1.2.0
Reporter: Jeremy Bauer

A Java EE application with query result caching enabled and with many concurrent users is failing with a ConcurrentModificationException in org.apache.openjpa.datacache.QueryCacheStoreQuery. Specifically, the failure is in the inner class.method CachingResultObjectProvider.checkFinished(Object, boolean) and occurs while iterating the _data TreeMap within the QueryResult constructor.

Examination of this method showed that the tree map is synchronized in the beginning of the method and then later when the map is cleared in abortCaching(). It is not synchronized when a new QueryResult is constructed. This allows a thread to iterate over the map (during the constructor) while another thread is modifying it.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: OpenJPA Developers

Mass insert; @SequenceGenerator allocationSize ignored?

2008-07-07T04:46:45Z

Hi guys,

My environment: JBOSS 4.2.1, OpenJPA 1.1, Java 5, EJB 3 (+JPA), build time
enhancement, many entities, Oracle 10g

We are currently inserting a lot of entities. Therefore we use a common
sequence (inherited from a @MappedSuperClass):

@Id
@SequenceGenerator(name = "SeqGen", allocationSize = 100, sequenceName =
"SEQ")
@GeneratedValue(strategy = GenerationType.SEQUENCE, generator = "SeqGen")
public int getId()
{
return id;
}

When creating 1000 entities and then call em.flush(), OpenJPA first performs
1000 times

SELECT SEQ.NEXTVAL from dual;

It then executes the 1000 insert statements (hopefully in batch). When
looking at the allocationSize javadoc, I assumed, that it would create an
ORACLE sequence with INCREMENT_BY 100 and then catch a new sequence value
every 100 inserts?

Is my expectation for allocationSize wrong, or do I use it the wrong way?
Is there a better / other way to configure the expected sequence behavior?
The problem is that our application now has a huge overhead in performance
only to calculate the ID of the new entity.

Thank you in advance for your help!

bye, Georg
--
View this message in context: http://n2.nabble.com/Mass-insert--%40SequenceGenerator-allocationSize-ignored--tp363057p363057.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

From forum: OpenJPA Users

Bug in mapping.

2008-07-06T23:43:34Z

Hi there.

With entities generated from the database I keep getting such exceptions:
org.apache.openjpa.persistence.PersistenceException: Invalid value for
getInt() - 'N'

When I workaround one such exception, I get the next one, and it seems that
all of them occur on fields that are CHAR(1) not nullable in the database
and were mapped to char. Char is not even shown in the example code, which
means it might have skipped to be tested completely.

Seeing this as a global issue, I want to fix it globally. Can FieldStrategy
be an overall solution? And if yes, how do I introduce my strategy to
OpenJPA?

Hiran Chaudhuri

From forum: OpenJPA Users

Able to remove relation with ManyToMany and no cascade.

2008-07-05T00:02:09Z

I stumbled accross a test scenario and did not think it was working right. Before posting a bug, I wanted to check if this scenario was already addressed (either in this forum or other forums).

I have three tables:

STUDENT (SID INT, SFSTNM VCHAR10, SLSTNM VCHAR10)
TEAM (TID INT, NAME VCHAR10)
COLLEGE( STUDID INT - REFERENCING SID STUDENT table, TEAMID INT - REFERENCING TID of TEAM table)

STUDENT entity defines a owning relation of ManyToMany with TEAM as follows:

@ManyToMany ()
@JoinTable(name="COLLEGE", joinColumns=@JoinColumn(name="STUDID", referencedColumnName="SID"), inverseJoinColumns=@JoinColumn(name="TEAMID", referencedColumnName="TID"))
public List<Team> getTeamCollection() {
return teamCollection;
}

TEAM entity defines the inverse relation as below:

@ManyToMany(mappedBy="teamCollection")
public List<Student> getStudentList() {
return studentList;
}

Data in the tables is as follows:
Student
SID SFSTNM SLSTNM
----------- ---------- ----------
1 ONE LAST
2 TWO LAST

Team
TID TNAME
----------- ----------
100 TEAM 100
200 TEAM 200

College
STUDID TEAMID
----------- -----------
2 200
1 100
2 100
1 200

Scenario 1:
Using EntityManager, I find the Student entity with PK value "1". Access the team list and remove the entry in the list with TID "100". Now when I commit this transaction, the entry from intermediate table (COLLEGE) with STUDID "1" and TEAMID "100" is removed.

Scenario 2:
Using EntityManager, I find the Team entity with PK value "200". Access the student list and remove the entry in the list with SID "1". On comitting the transaction, no changes are noticed in the COLLEGE table.

Conclusion:
With this testing, I am able to conclude that, using owner side of ManyToMany relation, we can remove entries from JoinTable (with or without any cascade option - Yes, I tried with no cascade option, refresh cascade option), where as from the inverse side of ManyToMany, we are unable to remove.

I have looked up the JSR 220 and did not find any specific mention on this scenario. This seems like a bug in the implementation. Please let me know if this really is a bug, so I can submit a bug report.

Regards
Jitendra.

From forum: OpenJPA Users

OpenJPA-571

2008-07-04T09:51:58Z

Can someone look at issue OpenJPA-571? I noticed that apparently nobody
has taken it on and I'm the third person to get nailed by it - in my
case in a simple table-to-table copy operation. I got around it only by
replacing the failing persist() call with a brute-force JDBC INSERT
operation.

Thanks,

Tim

From forum: OpenJPA Developers

How to find cause for PersistenceException?

2008-07-04T09:16:55Z

Hi there.

On classes generated from a database with Netbeans 6.1 I get such an exception at runtime:
<openjpa-1.1.0-r422266:657916 nonfatal general error> org.apache.openjpa.persistence.PersistenceException: Invalid value for getInt() - 'N'

Now I can imagine that int is a wrong mapping for the regarding table column and I know which table is accessed - but how do I find out which column this message relates to?

Hiran Chaudhuri
_______________________________________________________________________
Jetzt neu! Schützen Sie Ihren PC mit McAfee und WEB.DE. 30 Tage
kostenlos testen. http://www.pc-sicherheit.web.de/startseite/?mc=022220

From forum: OpenJPA Users

Incredible set of statements

2008-07-04T04:03:26Z

I got Entity with relation to itself like :

public class ActionLog {

@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.EAGER)
@JoinColumn(name = "product_id", nullable = false)
private Product product;

@ManyToOne(cascade = {CascadeType.MERGE, CascadeType.REFRESH}, fetch =
FetchType.EAGER)
@JoinColumn(name = "parent_id", nullable = true)
private ActionLog parent;

@OneToMany(cascade = CascadeType.ALL, fetch = FetchType.EAGER, mappedBy =
"parent")
@OrderBy(value = "created DESC")
private List<ActionLog> children = new ArrayList<ActionLog>();

}

When I execute named query to load Product with ActionLogs :
SELECT p FROM Product p LEFT JOIN FETCH p.logs WHERE p.id = :id
OpenJPA generates strange set of select.

At first is selects all ActionLogs for specified Product - it's OK. But next
it build single statement to select children of each ActionLog has been
found in the first step.

Couldn't it be made simplier?

Beniamin

-----
--
thanks
Beniamin
--
View this message in context: http://n2.nabble.com/Incredible-set-of-statements-tp221053p221053.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

thanks
Beniamin

From forum: OpenJPA Users

1st level cache and query statistics?

2008-07-04T00:49:35Z

Hello guys,

My environment: JBOSS 4.2.1, OpenJPA 1.1, Java 5, EJB 3 (+JPA), build time
enhancement, many entities

I currently try to get some statistics of the entity manger usage. JPA
provides no standardized way to find out how many entities are in the 1st
level cache. I only know it from Hibernate, it has a Session.getStatistics()
which returns basic information about the current session. More detailed
information is available on the SessionFactoy.

So now my question: Is there a similar way in OpenJPA? I would need the
following statistics:

1) EntityManager: how many entities (and collections) are in 1st level
cache?
2) EntityManagerFactory: how many select / insert / update statements were
executed within that SessionFactory?

If those informations are not available via API, how can I access them? Is
the 1st level cache in org.apache.openjpa.kernel.Broker?

Thank you for your help.

bye, Georg
--
View this message in context: http://n2.nabble.com/1st-level-cache-and-query-statistics--tp220964p220964.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.

From forum: OpenJPA Users

[jira] Commented: (OPENJPA-235) SQL reordering to avoid non-nullable foreign key constraint violations

2008-07-03T23:39:31Z

[ https://issues.apache.org/jira/browse/OPENJPA-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610463#action_12610463 ]

Roger Keays commented on OPENJPA-235:
-------------------------------------

Hi Fay, Your patch does actually work for me. I just needed to clean and rebuild. Thanks for that, I was tearing my hair out. Will we see the patch applied for 1.1.1?

> SQL reordering to avoid non-nullable foreign key constraint violations
> ----------------------------------------------------------------------
>
> Key: OPENJPA-235
> URL: https://issues.apache.org/jira/browse/OPENJPA-235
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Reece Garrett
> Assignee: Patrick Linskey
> Fix For: 1.2.0
>
> Attachments: merge-detached.patch, merge-testcases.patch, openjpa-235-break-nullable-070716.patch, openjpa-235-break-nullable.patch, openjpa-235-delete-cascade.patch, openjpa-235-test.jar, openjpa-235-test1.jar, openjpa-235-test2.zip, openjpa.patch, openjpa.patch, sqlreorder.patch, sqlReorder2.patch, sqlReorderTests.patch
>
>
> OpenJPA does not do any SQL statement re-ordering in order to resolve foreign key constraints. Instead, objects are always inserted in the order in which the user persists the instances. When you persist in an order that would violate foreign key constraints, OpenJPA attempts to insert null and then update the foreign key value in a separate statement. If you use non-nullable constraints, though, you must persist your objects in the correct order.
> This improvement re-orders SQL statements as follows:
> 1. First, all insert statements execute. Inserts which have foreign keys with non-nullable constraints execute AFTER the foreign keys which they depend on have been inserted since no deferred update is possible.
> 2. Next, all update statements execute. No reordering is necessary.
> 3. Finally, all delete statements execute. Like inserts, deletes execute in an order which does not violate non-nullable foreign key constraints.
> If a circular foreign key reference is found during the re-ordering process then re-ordering halts and the remaining unordered statements are left as is. There is nothing that can be done about the circular reference (other than fixing the schema) and the resulting SQL statements will not succeed.
> The net effect is that users do not need to worry about the persistence order of their objects regardless of non-nullable foreign key constraints. The only class modified was org.apache.openjpa.jdbc.kernel.OperationOrderUpdateManager. I have included a patch which includes my modifications to OperationOrderUpdateManager and test cases. The test cases I have provided fail on the current trunk but pass with my modifications. I have also verified that I did not break anything by using maven to run all test cases with my modifications in place.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: OpenJPA Developers

svn commit: r673855 - in /openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test: PersistenceTestCase.java SingleEMFTestCase.java

2008-07-03T15:41:07Z

Author: ppoddar
Date: Thu Jul 3 15:41:07 2008
New Revision: 673855

URL: http://svn.apache.org/viewvc?rev=673855&view=rev
Log:
OPENJPA-652: Formatting to be published base TestCases

Modified:
openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/PersistenceTestCase.java
openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/SingleEMFTestCase.java

Modified: openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/PersistenceTestCase.java
URL: http://svn.apache.org/viewvc/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/PersistenceTestCase.java?rev=673855&r1=673854&r2=673855&view=diff
==============================================================================
--- openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/PersistenceTestCase.java (original)
+++ openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/PersistenceTestCase.java Thu Jul 3 15:41:07 2008
@@ -43,10 +43,15 @@
extends TestCase {

/**
- * Marker object you an pass to {@link #setUp} to indicate that the
- * database tables should be cleared.
+ * Marker object you pass to {@link #setUp} to indicate that the
+ * database table rows should be cleared.
*/
protected static final Object CLEAR_TABLES = new Object();
+
+ /**
+ * Marker object you pass to {@link #setUp} to indicate that the
+ * database table should be dropped and then recreated.
+ */
protected static final Object DROP_TABLES = new Object();

/**
@@ -152,7 +157,8 @@
}

/**
- * Closes all open entity managers after first rolling back any open transactions
+ * Closes all open entity managers after first rolling back any open
+ * transactions.
*/
protected void closeAllOpenEMs(EntityManagerFactory emf) {
if (emf == null || !emf.isOpen())
@@ -196,15 +202,17 @@
protected void clear(EntityManagerFactory emf) {
if (emf == null)
return;
- clear(emf, true, ((OpenJPAEntityManagerFactorySPI) emf).getConfiguration().
- getMetaDataRepositoryInstance().getMetaDatas());
+ clear(emf, true, ((OpenJPAEntityManagerFactorySPI) emf)
+ .getConfiguration()
+ .getMetaDataRepositoryInstance().getMetaDatas());
}

/**
* Delete all instances of the given types using bulk delete queries.
* @param closeEMs TODO
*/
- private void clear(EntityManagerFactory emf, boolean closeEMs, ClassMetaData... types) {
+ private void clear(EntityManagerFactory emf, boolean closeEMs,
+ ClassMetaData... types) {
if (emf == null || types.length == 0)
return;

Modified: openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/SingleEMFTestCase.java
URL: http://svn.apache.org/viewvc/openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/SingleEMFTestCase.java?rev=673855&r1=673854&r2=673855&view=diff
==============================================================================
--- openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/SingleEMFTestCase.java (original)
+++ openjpa/trunk/openjpa-persistence-jdbc/src/test/java/org/apache/openjpa/persistence/test/SingleEMFTestCase.java Thu Jul 3 15:41:07 2008
@@ -21,6 +21,17 @@
import org.apache.openjpa.jdbc.meta.ClassMapping;
import org.apache.openjpa.persistence.OpenJPAEntityManagerFactorySPI;

+/**
+ * Base class for OpenJPA-specific Test Case.
+ * Provides utilities for configuration setup and persistent entity
+ * registration during setUp() method.
+ * Derived classes can access protected EntityManagerFactory to create
+ * EntityManager. The protected EntityManagerFactory is declared to be
+ * OpenJPA-extended SPI interface <code>OpenJPAEntityManagerFactorySPI</code>
+ * so that derived classes can access internal mapping/metadata/configuration
+ * and other structures.
+ *
+ */
public abstract class SingleEMFTestCase
extends PersistenceTestCase {

@@ -71,8 +82,7 @@
/**
* Get the class mapping for a given entity
*
- * @param name
- * The Entity's name.
+ * @param name The Entity's name.
*
* @return If the entity is a known type the ClassMapping for the Entity
* will be returned. Otherwise null

From forum: OpenJPA Commits

[CONF] OpenJPA: HowToWriteTestCaseForOpenJPA (page edited)

2008-07-03T15:16:01Z

Page Edited : openjpa : HowToWriteTestCaseForOpenJPA

HowToWriteTestCaseForOpenJPA has been edited by Pinaki Poddar (Jul 03, 2008).

(View changes)

Content:

How to write TestCase for OpenJPA?

OpenJPA Unit Tests are JUnit Tests. Base JUnit TestCase (org.junit.TestCase) has been extended to facilitate common initialization steps or configuration settings required for unit testing OpenJPA. As a test developer, you should inherit your test class from one of the extended TestCases. This also helps the test you write to be integrated with OpenJPA test corpus of approximately 2000 test cases in 400 classes.
The inheritance hierarchy is:

junit.framework.TestCase
    org.apache.openjpa.persistence.test.PersistenceTestCase
        org.apache.openjpa.persistence.test.SingleEMFTestCase
            org.apache.openjpa.persistence.test.SQLListenerTestCase

SingleEMFTestCase is a good candidate for inheritance unless your test needs to analyze or count number of SQL statements in which case SQLListenerTestCase should be your choice.

Setting up the test

JUnit tests are setup in their setUp method. OpenJPA TestCases augment the setUp() method to accept a list of arguments. In this list, you should specify

the domain classes used by your test
the configuration properties that are critical to your test
CLEAR_TABLES or DROP_TABLES : these are constants declared in the superclass which clears the rows or drops the tables altogether.

The following example shows how to declare setUp() method in your test class

public void setUp() throws Exception {
    setUp(CLEAR_TABLES,                      // clears rows from PERSON and ADDRESS table
          Person.class, Address.class,       // registers Person and Address as persistence-capable entity
          "openjpa.Multithreaded", "true");  // sets configuration property as name-value pair
}

Configuration of Persistence Unit

Notice that some configuration parameters can be set in the setUp() method of test program itself. This is recommended for properties that are important for your test. The non-critical parameters such as database connection properties (unless your test is about some specific aspect of a particular database) are better be specified in META-INF/persistence.xml.

The name of the persistence unit is, by default, "test". But your test should overwrite the name with a more specific unit name. For example,

protected String getPersistenceUnitName() {
    return "test-eager-fetch";
}

Cleaning Up

Specifying CLEAR_TABLES or DROP_TABLES in the list of setUp() parameters helps to minimize impact of one test on another. Remember that the test you are writing will run with 2000 other tests in a batch.

JUnit TestCases invoke tearDown() method on termination. SingleEMFTestCase ensures that tearDown() method deletes all rows for the classes involved in your test. While clear-your-own-mess helps in most situations, you may want the database records to remain for analysis especially when tests are failing. In that case you may consider suppressing the superclass behavior of tearDown() by simply nullifying the method as

public void tearDown() throws Exception {
     // avoids super class to delete all records
}

Naming Convention

Name your test class and test methods with following guideline in mind

Test case class names start with "Test" e.g. TestEagerFetch
Test method names start with "test" e.g. testUpdateHonoursForeignKeyConstraints()
Be generously descriptive with camel case e.g. TestEagerFetch or testFetchGroupLocking()
avoid the obvious e.g. TestSelect or testQuery()

Domain classes

Domain classes should avoid common names such as Person or Address.
Prefer annotation over XML Descriptors for O-R Mapping because that helps to colocate relevant information. Unless, of course, the test is specific about variations in behavior across annotation and XML Descriptors.

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

From forum: OpenJPA Commits

[CONF] OpenJPA: HowToWriteTestCaseForOpenJPA (page created)

2008-07-03T15:10:02Z

Page Created : openjpa : HowToWriteTestCaseForOpenJPA

HowToWriteTestCaseForOpenJPA has been created by Pinaki Poddar (Jul 03, 2008).

Content:

How to write TestCase for OpenJPA?

OpenJPA Unit Tests are JUnit Tests. Base JUnit TestCase (org.junit.TestCase) has been extended to faciliate common initialization steps or configuration settings required for unit testing OpenJPA. As a test develpoer, you should inherit your test class from one of the extended TestCases. This also helps the test you write to be integrated with OpenJPA test corpus of approximately 2000 test cases in 400 classes.
The inheritence hierarchy is:

org.junit.TestCase
    org.apache.openjpa.persistence.test.PersistenceTestCase
        org.apache.openjpa.persistence.test.SingleEMFTestCase
            org.apache.openjpa.persistence.test.SQLListenerTestCase

SingleEMFTestCase is a good candidate for inheritance unless your test needs to analyze or count number of SQL statements in which case SQLListenerTestCase should be your choice.

Setting up the test

JUnit tests are setup in their setUp method. OpenJPA TestCases augment the setUp() method to accept a list of arguments. In this list, you should specify

the domain classes used by your test
the configuration properties that are critical to your test
CLEAR_TABLES or DROP_TABLES : these are constants declared in the superclass which clears the rows or drops the tables altogether.

The following example shows how to declare setUp() method in your test class

public void setUp() throws Exception {
    setUp(CLEAR_TABLES,                      // clears rows from PERSON and ADDRESS table
          Person.class, Address.class,       // registers Person and Address as persistence-capable entity
          "openjpa.Multithreaded", "true");  // sets configuration property as name-value pair
}

Configuration of Persistence Unit

The name of the persistence unit is, by default, "test". But your test should overwrite the name with a more specific unit name. For example,

protected String getPersistenceUnitName() {
    return "test-eager-fetch";
}

Cleaning Up

public void tearDown() throws Exception {
     // avoids super class to delete all records
}

Naming Convention

Name your test class and test methods with following guideline in mind

Test case class names start with "Test" e.g. TestEagerFetch
Test method names start with "test" e.g. testUpdateHonoursForeignKeyConstraints()
Be generously descriptive with camel case e.g. TestEagerFetch or testFetchGroupLocking()
avoid the obvious e.g. TestSelect or testQuery()

Domain classes

Domain classes should avoid common names such as Person or Address.
Prefer annotation over XML Descriptors for O-R Mapping because that helps to colocate relevant information. Unless, of course, the test is specifc about variations in behavior across annotation and XML Descriptors.

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

From forum: OpenJPA Commits

[jira] Created: (OPENJPA-652) Collaborative Testing: provide resources/tools to facilitate user community to contribute unit tests for OpenJPA

2008-07-03T10:51:45Z

Collaborative Testing: provide resources/tools to facilitate user community to contribute unit tests for OpenJPA
------------------------------------------------------------------------------------------------------------------

Key: OPENJPA-652
URL: https://issues.apache.org/jira/browse/OPENJPA-652
Project: OpenJPA
Issue Type: New Feature
Components: build / infrastructure
Reporter: Pinaki Poddar

A growing body of developers are using OpenJPA and reporting their use case scenarios, error report via the Nabble posts. This process generates wealth of unstructured information.

Here is a proposal to add some more structure to it:

1. We publish and distribute the common utilities of OpenJPA's JUnit based test harness.
2. We request/mandate that submission of a JIRA report accompany a test case written in accordance to OpenJPA-JUnit based tests.

This way, we can build a diverse test corpus gradually.

To get this done, we need to
1. Document our JUnit Test harness related classes (such as SingleEMFTestCase etc.). They already are well-documented -- perhaps a small write-up on 'How to write OpenJPA test' manual.
2. Extend our build so that these tests classes are distributed with their source code in a separate bundle.
3. Promote the users' to contribute their test cases

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

From forum: OpenJPA Developers

Callback to/from entity transactions

2008-07-03T08:57:01Z

Hi,

Q: Is there a way to access/get back exceptions thrown within the persistance/transaction layer?

Example:
Code (pseudo):
Sateless session bean::SomeEntity someMethod( SomeEntity entity ) {
return this.getEntityManager().merge( entity );
}

Server:
Caused by: org.apache.openjpa.lib.jdbc.ReportingSQLException:
Duplicate entry '0-shortname 1-0000-00-00 00:00:00' for key 2

Client:
Will get SomeEntity with all fields set to null/default.

Well - I would have expected something like 'null' to be returned or an exception to be thrown, but I have to admit I did not yet fully read the specs... Nvm I can handle the returned value anyway.
But:
I'd like to give the user a feedback like "... already exists!" which I can do soley if I get access to the exception thrown on the transaction layer. Is there something like @TransactionCallback?
Or maybe I went wrong somwhere else?

Thank you in advance.
--
Psssst! Schon das coole Video vom GMX MultiMessenger gesehen?
Der Eine für Alle: http://www.gmx.net/de/go/messenger03

From forum: OpenJPA Users

Collaborative Testing

2008-07-03T08:50:14Z

Hi,
A growing body of developers are using OpenJPA and reporting their use
case scenarios, error report via the Nabble posts. This process generates
wealth of unstructured information.

Here is a proposal to add some structure to it:

1. We publish and distribute the common utilities of OpenJPA's JUnit based
test harness.
2. We request/mandate that submission of a JIRA report accompany a test case
written in accordance to OpenJPA-JUnit based tests.

This way, we can build a diverse test corpus gradually.

To get this done, we need to
1. Document our JUnit Test harness related classes (such as
SingleEMFTestCase etc.). They already are well-documented -- perhaps a small
write-up on 'How to write OpenJPA test' manual.
2. Extend our build so that these tests classes are distributed with their
source code in a separate bundle.
3. Promote the users' to contribute their test cases

--
View this message in context: http://n2.nabble.com/Collaborative-Testing-tp220418p220418.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.

From forum: OpenJPA Developers

Query to return shared data for performance reasons.

2008-07-03T08:31:18Z

hello,

Im interested in helping openjpa to implement that query can return
shared objects from the cache.

On many usage cases its only of interest to read data, no need to get a
clone/copy then.
(and yes its up to the user to not actually edit the returned data.)

This exists in eclipselink and works good, QueryHints.READ_ONLY.

Could i please get some initial help, where to do this in the code base
in a nice way ?.

regards
gustav

From forum: OpenJPA Users

[CONF] OpenJPA: FAQ (comment added)

2008-07-03T07:07:00Z

Comment Added : openjpa : Re: FAQ

FAQ commented on by Michael Dick (Jul 03, 2008).

Comment:

Thanks for pointing these out Jonas. I've updated the page.

Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request

Unsubscribe or edit your notifications preferences

From forum: OpenJPA Commits