Hi Gokhan,
I've been trying to play around with the code you provided on this issue.
Unlike the 5mins quick start examples provided for the OpenJPA download, the
build.xml wasn't a straightforward
root for creating an Eclipse project. So, I did that by some manual
importing.
I've reached the point where I'm being told:
------------------------------------------------------------------------------
[java] javax.persistence.PersistenceException: Invalid or inaccessible
provider class: org.apache.openjpa.persistence.PersistenceProviderImpl
[java] at org.apache.tools.ant.taskdefs.ExecuteJava.execute(
ExecuteJava.java:180)
[java] at org.apache.tools.ant.taskdefs.Java.run(Java.java:710)
------------------------------------------------------------------------------
Still cryptic to me. I'll try again later.. For now, what my little bit of
poking around yields is the following question:
Is the use of <taskdef name="openjpac" classname="
org.apache.openjpa.ant.PCEnhancerTask"/>
the equivalent of what is done for the examples with
<!--
Specifying the openjpa jar as the javaagent argument is
necessary in order for automatic class-enhancement to work.
-->
<jvmarg value="-javaagent:${javaagent}"/> ?
Any ideas on my stack trace above? (I don't have an explicit provider
setting in persistence.xml)
J-Philippe.
On 5/3/07, Gokhan Ergul (JIRA) <[EMAIL PROTECTED]> wrote:
[
https://issues.apache.org/jira/browse/OPENJPA-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12493193]
Gokhan Ergul commented on OPENJPA-231:
--------------------------------------
Further testing reveals that the patch I submitted solves only detached
object merge case. Persisting and later merging in a single EntityManager
session produces unreliable results, sometimes insert statements of C
precede insert statements of B resulting in a FK violation, other times the
statements are executed in the correct order --I have no idea as to why the
order would change in different test runs with identical configuration.
> Incorrect handling of cascading bidirectional collections during
merge/attach
>
-----------------------------------------------------------------------------
>
> Key: OPENJPA-231
> URL: https://issues.apache.org/jira/browse/OPENJPA-231
> Project: OpenJPA
> Issue Type: Bug
> Components: kernel
> Affects Versions: 0.9.7
> Environment: platform-independent
> Reporter: Gokhan Ergul
> Attachments: jira-test-case.zip
>
>
> As posted on open-jpa-dev mailing list:
> -----
> I'm having a problem merging an entity, here's the simplified structure:
> Class A { @OneToMany(cascade=CascadeType.ALL, mappedBy="parent")
> Set<B> b_set;
> ...
> }
> Class B {
> @ManyToOne
> A parent;
> @OneToMany(cascade=CascadeType.ALL, mappedBy="parent")
> Set<C> c_set;
> ...
> }
> Class C {
> @ManyToOne
> B parent;
> ...
> }
> New instances of A,B,C are persisted correctly. However when I retrieve
A, add some entries to A.b_set (with some of the new B entries have
attached C's), em.merge(A) fails:
> - If A is detached:
> org.apache.openjpa.persistence.ArgumentException: Encountered new
object "[EMAIL PROTECTED]" in persistent field "C.parent" of managed object "[EMAIL
PROTECTED]"
during attach. However, this field does not allow cascade attach. You
cannot attach a reference to a new object without cascading.
> - If A is not detached:
> C instances are inserted before B instances, resulting
in a foreign key violation.
> Setting openjpa.jdbc.SchemaFactory to 'native(ForeignKeys=true)' does
not seem to have an effect.
> ----
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
