Hi!
Sorry for not replying until now, have been on 4 weeks of vacation.
I'm glad to see that it was actually a bug because I was starting to think
that I was doing something terribly wrong :) If i remember everything
correct I also tried the latest version back then (1.2.1) and the outcome
was
up : any advice on that point ?
On Aug 8, 2009, at 08:57 , Jean-Baptiste BRIAUD -- Novlog wrote:
Hi,
say I have one instance to delete, an instance of B knowing that A
contains one to many B.
Should I merge A with one less B, that should delete the required B
or should I explicitly
I tried the new 1.2.1 binaries and it actually worked fine which comes as a
surprise to me since im quite sure about testing it for a couple of weeks
ago :) Anyway I will try this version for a while and if I find any more
related problems I will post it here!
Thanks!
/ Ulf
ulfherge wrote:
Hi ,
I guess, If you mergeA with one less B , then the association between A and B
will be lost but the instance of B will not be deleted.
If you call em.remove(B) then the instance of B (corresponding row in B) will
be deleted.
Delete by query also should remove the instance of B.
If memory
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
On Thu, Aug 13, 2009 at 9:26 AM, ljnelson (via Nabble)
ml-user+210534-64246...@n2.nabble.comml-user%2b210534-64246...@n2.nabble.com
wrote:
Here is a snippet of the stack:
Caused by: openjpa-1.3.0-SNAPSHOT-r422266:803348 nonfatal general error
ljnelson wrote:
Doh! I didn't include the final caused-by:
Caused by: java.lang.Exception: java.lang.IndexOutOfBoundsException:
Index:
3, Size: 3
at
org.apache.openjpa.util.Exceptions.replaceNestedThrowables(Exceptions.java:249)
at
From the description in the JIRA [1], it seems that this problem is related
to the QuerySQLCache [2] that is on by default. As a workaround, you
should be able to turn off this property and get around the problem. A
replacement implementation for this particular cache has been incorporated
into
On Thu, Aug 13, 2009 at 10:19 AM, Kevin Sutter (via Nabble)
ml-user+17993-2124421...@n2.nabble.comml-user%2b17993-2124421...@n2.nabble.com
wrote:
From the description in the JIRA [1], it seems that this problem is related
to the QuerySQLCache [2] that is on by default. As a workaround, you
On Thu, Aug 13, 2009 at 10:19 AM, Kevin Sutter (via Nabble)
ml-user+17993-2124421...@n2.nabble.comml-user%2b17993-2124421...@n2.nabble.com
wrote:
From the description in the JIRA [1], it seems that this problem is related
to the QuerySQLCache [2] that is on by default.
First of all, my
It looks like Mike just took ownership of OPENJPA-1001. My guess is that
the first approach at resolving this issue will be to resolve this specific
issue, and not the whole QuerySQLCache re-architecture. I would monitor
that JIRA and comment directly on that JIRA.
Thanks,
Kevin
On Thu, Aug
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
I didn't quite get what you were trying to describe but in my case I have E1
and E2 joined as many to many. In any case that I make a change to E1 I only
want it remained linked to the E2 entity, not making any changes to any E2
entity since E2 is persisted as a stand-alone entity.
In this case
For my 2c worth. Delete by query might be cheaper, but for me it breaks the
ORMS model. The model relationships should manage all aspects of the model.
Performing a query in a true ORMS model seems to be a patch up job.
Just my 2c,
Chris
-Original Message-
From: Ravi Palacherla
On Thu, Aug 13, 2009 at 1:10 PM, crispyoz (via Nabble)
ml-user+243560-833017...@n2.nabble.comml-user%2b243560-833017...@n2.nabble.com
wrote:
I didn't quite get what you were trying to describe
Let me try again.
I have multiple mappings for the same column. Of those multiple mappings,
only
Hi,
I'm looking to extend OpenJPA's entity manager to provide some additional
methods. Based on my reading, it seems like I can extend both the default
EntityManagerFactory and the default EntityManager. However, I can't seem
to find any information on how to actually do this. Any pointers are
I have been experimenting with OpenJPA and JAXB with regard to storing and
retrieving XML from an DB2 9.7 database and I've run into a problem. I've
gone through the steps of creating a simple XML schema and generating the
Java classes using xjc. I have followed the steps in the OpenJPA manual
Hi Laird,
I also think that you should get a NON-NULL for e2.gete1() after flush,
provided e2 is managed at the time you are doing e2.gete1().
What if you do
e2 = em.find(e2.class,PK);
e2.gete1();
then are you getting a non-null e1 value ?
Regards,
Ravi.
-Original Message-
From:
On Thu, Aug 13, 2009 at 4:39 PM, Ravi P Palacherla (via Nabble)
ml-user+194843-327306...@n2.nabble.comml-user%2b194843-327306...@n2.nabble.com
wrote:
Hi Laird,
I also think that you should get a NON-NULL for e2.gete1() after flush,
provided e2 is managed at the time you are doing
Heather,
Yes, the EMF and EM implementations can be extended. There's nothing
preventing that, but this makes it sound like you might be interested in
providing your own flavor of OpenJPA as a Persistence Provider. This is
also doable, but this might be more work than you think. Can I ask why
Hi,
I think I found a better solution.
after flush()
call em.refresh(e2)
This will refresh the state of e2 from the datastore.
now e2.gete1() should return NON-NULL value.
Previously, it was not working because even though flush() updates the
datastore with values of e2.
The next call
In addition to Ravi's comments it sounds like there's a different in which
fields are eagerly / lazily fetched. Which version of OpenJPA are you using
for the RESOURCE_LOCAL tests (there is a change this behavior recently so
trunk might be different from say 1.2.1).
-mike
On Mon, Jul 27, 2009 at
Mike,
Thanks a lot!
Since I used DBCP datasource as following:
property name=openjpa.ConnectionProperties
value=driverClassName=oracle.jdbc.driver.OracleDriver,
url=jdbc:oracle:thin:@localhost:1521:orcl, username=XXX, password=XXX,
Hi,
OpenJPA doesn't know (or care) how much of the password is encrypted - that
determination is up to the encryption provider (ie your code). So if the
encryption provider can figure out which parts of the string need to be
decrypted and which parts do not then you should be set.
I just reopened
24 matches
Mail list logo
