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 <[email protected]> > 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 <[email protected]> > >> 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 < >> [email protected]> 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 <[email protected]> >> > >> >> 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 < >> >> [email protected]> 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) >> >> >> >> >> >> >
