You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by David Blevins <da...@visi.com> on 2009/01/26 08:33:33 UTC

Compound custom id in bidirectional many-to-one

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 sql is  
correctly generated with the foreign keys in the where clause lining  
up to the sql perfectly, but the there seems to be a second pass where  
the parameter values are collected in what *appears* to be  
alphabetical order.  When setParameters(..) is called the orders of  
the params are not guaranteed to match and can result in an invalid  
select statement.

More details here:  https://issues.apache.org/jira/browse/OPENJPA-872

Just a note, I've taken the liberty to mark it as "blocker" as this  
regression is causing a small set of TCK failures which is affecting  
the pending Geronimo 2.1.4 and 2.2 releases.  The area isn't actually  
the JPA side of the TCK but rather the EJB/CMP20 side (i.e. the  
OpenEJB CMP/JPA bridge).

I've included a small test case which replicates the issue.  It uses a  
container managed entity manager, but could easily be reworked for  
standalone jpa -- was just easier to get something running this way.

-David




Re: Request for a OpenJPA 1.2.1 release

Posted by Joe Bohn <jo...@earthlink.net>.
Thanks for the update Mike.  And thanks for all you've done getting 
issues resolved and pulling together this release.

Joe


Michael Dick wrote:
> It's building now. I ran into weird issues with the release plugin last
> night but I think I've ironed those out.
> 
> Should have a release candidate tonight / tomorrow.
> 
> -mike
> 
> On Wed, Mar 4, 2009 at 12:39 PM, Joe Bohn <jo...@earthlink.net> wrote:
> 
>> Hi Mike,
>>
>> How are things looking for the 1.2.1 release?  Do you anticipate having a
>> release candidate soon?
>>
>> Thanks,
>> Joe
>>
>>
>>
>> Michael Dick wrote:
>>
>>> Sure, I'll start on it later this afternoon / tonight.
>>>
>>> -mike
>>>
>>> On Mon, Mar 2, 2009 at 9:42 AM, Donald Woods <dw...@apache.org> wrote:
>>>
>>>  Everything is a go from the Geronimo side, as we got a clean TCK run
>>>> completed.  Can we start a OpenJPA 1.2.1 release now?
>>>>
>>>>
>>>> Thanks,
>>>> -Donald
>>>>
>>>>
>>>>
>>>> Donald Woods wrote:
>>>>
>>>>  Mike, it looks like all of our TCK failures related to JPA have been
>>>>> fixed
>>>>> and verified.  Can you start the process of cutting a 1.2.1 branch
>>>>>  while we
>>>>> finish our TCK runs?  I'd still wait until we have the complete results
>>>>> in
>>>>> (probably sometime Friday) before you start a RC vote.
>>>>>
>>>>> Thanks,
>>>>> Donald
>>>>>
>>>>>
>>>>> Michael Dick wrote:
>>>>>
>>>>>  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 <kevan.miller@gmail.com
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>  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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>>>>>>
>>>>>>> --kevan
>>>>>>>
>>>>>>>
> 


Re: Request for a OpenJPA 1.2.1 release

Posted by Michael Dick <mi...@gmail.com>.
It's building now. I ran into weird issues with the release plugin last
night but I think I've ironed those out.

Should have a release candidate tonight / tomorrow.

-mike

On Wed, Mar 4, 2009 at 12:39 PM, Joe Bohn <jo...@earthlink.net> wrote:

> Hi Mike,
>
> How are things looking for the 1.2.1 release?  Do you anticipate having a
> release candidate soon?
>
> Thanks,
> Joe
>
>
>
> Michael Dick wrote:
>
>> Sure, I'll start on it later this afternoon / tonight.
>>
>> -mike
>>
>> On Mon, Mar 2, 2009 at 9:42 AM, Donald Woods <dw...@apache.org> wrote:
>>
>>  Everything is a go from the Geronimo side, as we got a clean TCK run
>>> completed.  Can we start a OpenJPA 1.2.1 release now?
>>>
>>>
>>> Thanks,
>>> -Donald
>>>
>>>
>>>
>>> Donald Woods wrote:
>>>
>>>  Mike, it looks like all of our TCK failures related to JPA have been
>>>> fixed
>>>> and verified.  Can you start the process of cutting a 1.2.1 branch
>>>>  while we
>>>> finish our TCK runs?  I'd still wait until we have the complete results
>>>> in
>>>> (probably sometime Friday) before you start a RC vote.
>>>>
>>>> Thanks,
>>>> Donald
>>>>
>>>>
>>>> Michael Dick wrote:
>>>>
>>>>  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 <kevan.miller@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>  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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>>>>>
>>>>>> --kevan
>>>>>>
>>>>>>
>>>>>
>>
>

Re: Request for a OpenJPA 1.2.1 release

Posted by Joe Bohn <jo...@earthlink.net>.
Hi Mike,

How are things looking for the 1.2.1 release?  Do you anticipate having 
a release candidate soon?

Thanks,
Joe


Michael Dick wrote:
> Sure, I'll start on it later this afternoon / tonight.
> 
> -mike
> 
> On Mon, Mar 2, 2009 at 9:42 AM, Donald Woods <dw...@apache.org> wrote:
> 
>> Everything is a go from the Geronimo side, as we got a clean TCK run
>> completed.  Can we start a OpenJPA 1.2.1 release now?
>>
>>
>> Thanks,
>> -Donald
>>
>>
>>
>> Donald Woods wrote:
>>
>>> Mike, it looks like all of our TCK failures related to JPA have been fixed
>>> and verified.  Can you start the process of cutting a 1.2.1 branch  while we
>>> finish our TCK runs?  I'd still wait until we have the complete results in
>>> (probably sometime Friday) before you start a RC vote.
>>>
>>> Thanks,
>>> Donald
>>>
>>>
>>> Michael Dick wrote:
>>>
>>>> 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 <kevan.miller@gmail.com
>>>>> wrote:
>>>>  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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>>>>
>>>>> --kevan
>>>>>
>>>>
> 


Re: Request for a OpenJPA 1.2.1 release

Posted by Michael Dick <mi...@gmail.com>.
Sure, I'll start on it later this afternoon / tonight.

-mike

On Mon, Mar 2, 2009 at 9:42 AM, Donald Woods <dw...@apache.org> wrote:

> Everything is a go from the Geronimo side, as we got a clean TCK run
> completed.  Can we start a OpenJPA 1.2.1 release now?
>
>
> Thanks,
> -Donald
>
>
>
> Donald Woods wrote:
>
>> Mike, it looks like all of our TCK failures related to JPA have been fixed
>> and verified.  Can you start the process of cutting a 1.2.1 branch  while we
>> finish our TCK runs?  I'd still wait until we have the complete results in
>> (probably sometime Friday) before you start a RC vote.
>>
>> Thanks,
>> Donald
>>
>>
>> Michael Dick wrote:
>>
>>> 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 <kevan.miller@gmail.com
>>> >wrote:
>>>
>>>  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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>>>
>>>> --kevan
>>>>
>>>
>>>
>>

Re: Request for a OpenJPA 1.2.1 release

Posted by Donald Woods <dw...@apache.org>.
Everything is a go from the Geronimo side, as we got a clean TCK run 
completed.  Can we start a OpenJPA 1.2.1 release now?


Thanks,
-Donald


Donald Woods wrote:
> Mike, it looks like all of our TCK failures related to JPA have been 
> fixed and verified.  Can you start the process of cutting a 1.2.1 branch 
>  while we finish our TCK runs?  I'd still wait until we have the 
> complete results in (probably sometime Friday) before you start a RC vote.
> 
> Thanks,
> Donald
> 
> 
> Michael Dick wrote:
>> 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 
>> <ke...@gmail.com>wrote:
>>
>>> 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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>>
>>> --kevan
>>
> 

Re: Request for a OpenJPA 1.2.1 release

Posted by Donald Woods <dw...@apache.org>.
Everything is a go from the Geronimo side, as we got a clean TCK run 
completed.  Can we start a OpenJPA 1.2.1 release now?


Thanks,
-Donald


Donald Woods wrote:
> Mike, it looks like all of our TCK failures related to JPA have been 
> fixed and verified.  Can you start the process of cutting a 1.2.1 branch 
>  while we finish our TCK runs?  I'd still wait until we have the 
> complete results in (probably sometime Friday) before you start a RC vote.
> 
> Thanks,
> Donald
> 
> 
> Michael Dick wrote:
>> 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 
>> <ke...@gmail.com>wrote:
>>
>>> 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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>>
>>> --kevan
>>
> 

Request for a OpenJPA 1.2.1 release

Posted by Donald Woods <dw...@apache.org>.
Mike, it looks like all of our TCK failures related to JPA have been 
fixed and verified.  Can you start the process of cutting a 1.2.1 branch 
  while we finish our TCK runs?  I'd still wait until we have the 
complete results in (probably sometime Friday) before you start a RC vote.

Thanks,
Donald


Michael Dick wrote:
> 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 <ke...@gmail.com>wrote:
> 
>> 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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>
>> --kevan
> 

Request for a OpenJPA 1.2.1 release

Posted by Donald Woods <dw...@apache.org>.
Mike, it looks like all of our TCK failures related to JPA have been 
fixed and verified.  Can you start the process of cutting a 1.2.1 branch 
  while we finish our TCK runs?  I'd still wait until we have the 
complete results in (probably sometime Friday) before you start a RC vote.

Thanks,
Donald


Michael Dick wrote:
> 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 <ke...@gmail.com>wrote:
> 
>> 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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>>
>> --kevan
> 

Re: Compound custom id in bidirectional many-to-one

Posted by Michael Dick <mi...@gmail.com>.
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 <ke...@gmail.com>wrote:

>
> 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 avoid that... Meantime, we'll start using 1.2.1-SNAPSHOT
>
> --kevan

Re: Compound custom id in bidirectional many-to-one

Posted by Kevan Miller <ke...@gmail.com>.
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 avoid that... Meantime, we'll start using 1.2.1- 
SNAPSHOT

--kevan

Re: Compound custom id in bidirectional many-to-one

Posted by Kevin Sutter <kw...@gmail.com>.
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
different area of concern.  Thanks.

openjpa.jdbc.QuerySQLCache = false

Kevin

On Mon, Jan 26, 2009 at 1:33 AM, David Blevins <da...@visi.com>wrote:

> 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 sql is correctly
> generated with the foreign keys in the where clause lining up to the sql
> perfectly, but the there seems to be a second pass where the parameter
> values are collected in what *appears* to be alphabetical order.  When
> setParameters(..) is called the orders of the params are not guaranteed to
> match and can result in an invalid select statement.
>
> More details here:  https://issues.apache.org/jira/browse/OPENJPA-872
>
> Just a note, I've taken the liberty to mark it as "blocker" as this
> regression is causing a small set of TCK failures which is affecting the
> pending Geronimo 2.1.4 and 2.2 releases.  The area isn't actually the JPA
> side of the TCK but rather the EJB/CMP20 side (i.e. the OpenEJB CMP/JPA
> bridge).
>
> I've included a small test case which replicates the issue.  It uses a
> container managed entity manager, but could easily be reworked for
> standalone jpa -- was just easier to get something running this way.
>
> -David
>
>
>
>