cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: A small update
Date Fri, 05 Oct 2012 14:44:13 GMT
Cool. Let us know how that worked. And we are planning on some permanent changes to solve this
problem universally:

http://cayenne.markmail.org/thread/icr7seqazgsdtewc

On Oct 5, 2012, at 5:29 PM, Emanuele Maiarelli <maiarelli.emanuele@gmail.com> wrote:

> indeed i just noticed that tables having this kind of problem have PKs
> declared as numeric(38,0), this is something that postgress supports as
> oracle like types, but usually numeric primary keys are declared as bigint
> (or int since serials and bigserials are int and bigint)  , i'm gonna
> declare em as bigint too see what will happen.
> 
> Having pks declared as numeric(38,0) happened since these tables have been
> migated from oracle to postgress.
> 
> I'll give a try.
> 
> 
> 2012/10/5 Andrus Adamchik <andrus@objectstyle.org>
> 
>> I guess I need to run it in debugger with this driver version. I still
>> suspect some NUMERIC ambiguity issue.
>> 
>> Andrus
>> 
>> On Oct 5, 2012, at 5:04 PM, Emanuele Maiarelli <
>> maiarelli.emanuele@gmail.com> wrote:
>> 
>>> Problem persists after upgrading to cayenne 3.1B1.
>>> 
>>> org.apache.cayenne.CayenneRuntimeException: [v.3.1B1 May 28 2012
>> 20:59:56]
>>> Can't find id for {<ObjectId:Comuni, comuni_pk=4615>; committed;
>>> [toProvince=>?; anagraficheArray=>(..); comuniCap=>55049;
>>> comuniComIstat=>33; comuniCfPrefix=>L833; anagraficheArraySl=>(..);
>>> comuniDesc=>PROVA]}
>>>   at
>>> 
>> org.apache.cayenne.access.IncrementalFaultList$IncrementalListHelper.updateWithResolvedObjectInRange(IncrementalFaultList.java:677)
>>>   at
>>> 
>> org.apache.cayenne.access.IncrementalFaultList.resolveInterval(IncrementalFaultList.java:284)
>>>   at
>>> 
>> org.apache.cayenne.access.IncrementalFaultList.get(IncrementalFaultList.java:526)
>>>   at
>>> 
>> org.apache.cayenne.access.IncrementalFaultList$1.next(IncrementalFaultList.java:443)
>>> 
>>> Exception arise when running a paginated query, after to calling
>> "toComuni"
>>> method. Not paginated query instead works, as per cayenne 3.0.2.
>>> 
>>> Anyway underlaying database isn't oracle but postgress 9.1, jdbc driver
>>> postgresql-9.1-901.jdbc4.jar.
>>> 
>>> 
>>> 2012/10/5 Andrus Adamchik <andrus@objectstyle.org>
>>> 
>>>> Hi,
>>>> 
>>>>> If i call the method "toComuni" via reflection it fetchs the related
>>>>> object, but puts it in Hollow state (ex: {<ObjectId:Comuni,
>>>>> comuni_pk=4615>; hollow; []}).
>>>>> 
>>>>> I also noticed that if i fetch all "Comuni" objects with a select
>> query,
>>>>> before calling "toComuni" method via reflection, the object state is
>>>>> correcly as Committed.
>>>> 
>>>> 
>>>> This is expected. Relationships are read lazily. An object read via a
>>>> to-one relationship stays hollow until you call any of its methods. This
>>>> shouldn't cause any problems.
>>>> 
>>>>> org.apache.cayenne.CayenneRuntimeException: [v.3.0.2 Jun 11 2011
>>>> 09:26:09]
>>>>> Can't find id for {<ObjectId:Comuni, comuni_pk=4615>; committed;
>>>>> [toProvince=>?; anagraficheArray=>(..); comuniCap=>55049;
>>>>> comuniComIstat=>33; comuniCfPrefix=>L833; anagraficheArraySl=>(..);
>>>>> comuniDesc=>PROVA]}
>>>>>  at
>>>>> 
>>>> 
>> org.apache.cayenne.access.IncrementalFaultList$IncrementalListHelper.updateWithResolvedObjectInRange(IncrementalFaultList.java:701)
>>>>>  at
>>>> 
>>>> My guess is that with Oracle NUMERIC Cayenne may read a value for
>>>> "comuni_pk" as a different Java type, depending on whether the object
>> was
>>>> read via relationship or directly from DB. (e.g. Integer vs. BigDecimal
>> or
>>>> something). We had those issues before. If you run this in debugger and
>>>> poke inside ObjectId for Comuni, you will see whether this is the case.
>>>> 
>>>> Now how to fix it… first thing to try is to upgrade a step further to
>>>> Cayenne 3.1B1, as it addressed a few of those issues. If that doesn't
>> help,
>>>> we'll keep looking further.
>>>> 
>>>> Andrus
>>>> 
>>>> 
>>>> 
>>>> On Oct 5, 2012, at 2:02 AM, Emanuele Maiarelli <
>>>> maiarelli.emanuele@gmail.com> wrote:
>>>> 
>>>>> I tried to figureout a workaround to objects in hollow state.
>>>>> 
>>>>> Object value = toCall.invoke(p); // <- p is the getToComuni method
>>>>>          if (value instanceof Persistent)
>>>>>          {
>>>>>              Persistent pr=(Persistent)value;
>>>>> 
>>>>>              if (pr.getPersistenceState()==PersistenceState.HOLLOW)
>>>>>              {
>>>>>                  c.add(value);
>>>>> 
>>>> value=DataObjectUtils.objectForPK(Factory.getContext(),
>>>>> pr.getObjectId());
>>>>> 
>>>>>              }
>>>>> 
>>>>> 
>>>>>          }
>>>>> 
>>>>> the object after calling "DataObjectUtils.objectForPK(" comes i the
>>>> correct
>>>>> "Commited" state, but however fetching all "comuni" objects after
>>>> reflection
>>>>> throw the same exception, when the query is paginated.
>>>>> 
>>>>> That's the stack trace:
>>>>> 
>>>>> org.apache.cayenne.CayenneRuntimeException: [v.3.0.2 Jun 11 2011
>>>> 09:26:09]
>>>>> Can't find id for {<ObjectId:Comuni, comuni_pk=4615>; committed;
>>>>> [toProvince=>?; anagraficheArray=>(..); comuniCap=>55049;
>>>>> comuniComIstat=>33; comuniCfPrefix=>L833; anagraficheArraySl=>(..);
>>>>> comuniDesc=>PROVA]}
>>>>>  at
>>>>> 
>>>> 
>> org.apache.cayenne.access.IncrementalFaultList$IncrementalListHelper.updateWithResolvedObjectInRange(IncrementalFaultList.java:701)
>>>>>  at
>>>>> 
>>>> 
>> org.apache.cayenne.access.IncrementalFaultList.resolveInterval(IncrementalFaultList.java:306)
>>>>>  at
>>>>> 
>>>> 
>> org.apache.cayenne.access.IncrementalFaultList.get(IncrementalFaultList.java:550)
>>>>>  at
>>>>> 
>>>> 
>> org.apache.cayenne.access.IncrementalFaultList$1.next(IncrementalFaultList.java:467)
>>>> 
>>>> 
>> 
>> 


Mime
View raw message