cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emanuele Maiarelli <maiarelli.emanu...@gmail.com>
Subject Re: A small update
Date Fri, 05 Oct 2012 14:44:57 GMT
Ok, having primary keys declared as numeric(38,0) was the source of the
problem, also i noticed that foreing key of table anagrafiche, was a
bigint,that proly lead cayenne to errors.

I'm also surprised about postgress that usually is very strong typed, that
allowed me to build a relation between numeric type and a bigint.

Thank you for the hint Andrus,

Regards,

Emanuele

2012/10/5 Emanuele Maiarelli <maiarelli.emanuele@gmail.com>

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message