stom id in bidirectional many-to-one
> ---
>
> Key: OPENJPA-872
> URL: https://issues.apache.org/jira/browse/OPENJPA-872
> Project: OpenJPA
> Issue Type: Bug
>Affects Versions:
Hi Kevan,
I've been planning on doing a 1.2.1 release "real soon now" for a while.
I'll start working on it later this week (early next week at the latest).
Regards,
-mike
On Tue, Jan 27, 2009 at 11:04 AM, Kevan Miller wrote:
>
> Thanks Kevin and Jeremy for helping to resolve OPENJPA-872.
>
>
Thanks Kevin and Jeremy for helping to resolve OPENJPA-872.
Is there an outlook for an OpenJPA 1.2.1 release? Geronimo is going to
need a release prior to releasing Geronimo 2.1.4 and 2.2. I guess we
could consider using openjpa.jdbc.QuerySQLCache=false as a work-
around, but I'd rather avo
1.2.1-SNAPSHOT or adding this property:
to your persistence.xml will correct the problem.
> Compound custom id in bidirectional many-to-one
> ---
>
> Key: OPENJPA-872
> URL: https://issues.
Thanks, David, for the heads up and the JIRA issue. The first thought that
comes to mind is the sql caching support that was put into 1.2.0. As a
quick test, would you mind running with the following property? If turning
off the sql cache doesn't help your condition, then we've uncovered a
diffe
Seems there's a regression in custom id classes and bidirectional many-
to-one relationships. Haven't tried many-to-many but I suspect it
exists there as well.
It seems that the order of parameters filled into the SQLBuffer are
getting mixed. When the owning side's collection is loaded the
leverages openejb for
simplicity in the setup department. Should be no problem to rework it to
standalone jpa.
> Compound custom id in bidirectional many-to-one
> ---
>
> Key: OPENJPA-872
> URL: https://issues.
Compound custom id in bidirectional many-to-one
---
Key: OPENJPA-872
URL: https://issues.apache.org/jira/browse/OPENJPA-872
Project: OpenJPA
Issue Type: Bug
Affects Versions: 1.2.0
