Now works perfectly even on cayenne 3.0.2 2012/10/5 Andrus Adamchik <[email protected]>
> 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 < > [email protected]> 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 <[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) > >>>> > >>>> > >> > >> > >
