You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Emanuele Maiarelli <ma...@gmail.com> on 2012/10/05 01:02:10 UTC
A small update
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)
Re: A small update
Posted by Emanuele Maiarelli <ma...@gmail.com>.
Now works perfectly even on cayenne 3.0.2
2012/10/5 Andrus Adamchik <an...@objectstyle.org>
> 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 <an...@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 <an...@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)
> >>>>
> >>>>
> >>
> >>
>
>
Re: A small update
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <ma...@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 <an...@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 <an...@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)
>>>>
>>>>
>>
>>
Re: A small update
Posted by Emanuele Maiarelli <ma...@gmail.com>.
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 <ma...@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 <an...@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 <an...@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)
>> >>
>> >>
>>
>>
>
Re: A small update
Posted by Emanuele Maiarelli <ma...@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 <an...@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 <an...@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)
> >>
> >>
>
>
Re: A small update
Posted by Andrus Adamchik <an...@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 <ma...@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 <an...@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)
>>
>>
Re: A small update
Posted by Emanuele Maiarelli <ma...@gmail.com>.
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 <an...@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)
>
>
Re: A small update
Posted by Andrus Adamchik <an...@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 <ma...@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)