Okay, I created CAY-399.
P.S. I don't think I'll go with the #result workaround even though I
understand your point about it being a sure fix. For a large entity like
this, the sql string would be large and maintenance-prone. (53 macros,
needing updating every time we modify the entity.) I'm sticking with the
less elegant but easier work-around I have now, watching for an Integer
value in a couple of getter methods.
Thanks for the help.
----- Original Message -----
From: "Andrus Adamchik" <andru..bjectstyle.org>
To: <cayenne-use..bjectstyle.org>
Sent: Thursday, November 03, 2005 4:11 PM
Subject: Re: intermittent exception
> Yes, this confirms what I thought originally. Workaround here is to
> use #result directive for each column in the SQLTemplate per template
> scripting chapter:
>
> http://objectstyle.org/cayenne/userguide/fetch/sqltemplate-
> scripting.html
>
> The second form with Java type [#result(columnName javaType)] would
> be the best bet. It is more verbose than "select *", but leaves no
> uncertainty about the result.
>
> On the long run we should probably address this as a bug - there is
> enough information for Cayenne to make the right type conversions in
> such case. I'd appreciate a bug report.
>
> Andrus
>
>
> On Nov 3, 2005, at 11:13 PM, Bryan Lewis wrote:
>
> > Sounds like a darned good theory! It happens that the one example
> > I pasted
> > into my email didn't refer to objectsFromDataRows, but all the
> > other cases
> > I've seen (half a dozen) do. Here's one:
> >
> > at
> > org.objectstyle.cayenne.access.DataRowUtils.refreshObjectWithSnapshot(
> > DataRo
> > wUtils.java:102)
> > at
> > org.objectstyle.cayenne.access.DataRowUtils.mergeObjectWithSnapshot
> > (DataRowU
> > tils.java:240)
> > at
> > org.objectstyle.cayenne.access.DataContext.objectsFromDataRows
> > (DataContext.j
> > ava:724)
> > at
> > org.objectstyle.cayenne.access.util.PrefetchResolver.resolveObjectTree
> > (Prefe
> > tchResolver.java:225)
> > at
> > org.objectstyle.cayenne.access.util.PrefetchResolver.resolveObjectTree
> > (Prefe
> > tchResolver.java:197)
> > at
> > org.objectstyle.cayenne.access.util.SelectObserver.getResultsAsObjects
> > (Selec
> > tObserver.java:228)
> > at
> > org.objectstyle.cayenne.access.DataContextSelectAction.performQuery
> > (DataCont
> > extSelectAction.java:156)
> > at
> > org.objectstyle.cayenne.access.DataContextSelectAction.performQuery
> > (DataCont
> > extSelectAction.java:87)
> > at
> > org.objectstyle.cayenne.access.DataContext.performQuery
> > (DataContext.java:125
> > 2)
> > at com.seafax.logic.AdvancedSearch.tryQuery(AdvancedSearch.java:70)
> >
> > My tryQuery() method does use a SQLTemplate:
> >
> > SQLTemplate query = new SQLTemplate(Company.class, sql,
> > true);
> > list = dc.performQuery(query);
> >
> > but I'm not calling objectsFromDataRows() myself. Never needed
> > to... I
> > always got a nice list of Company objects from the query.
> >
> > A typical SQL string is:
> >
> > select n.* from nic n where (n.companynameupper like 'SOME NAME%')
> > and n.hidefromweb is null
> > order by companyname, nic_id
> >
> > I'm all ears for the workaround.
> >
> >
> >
> > ----- Original Message -----
> > From: "Andrus Adamchik" <andru..bjectstyle.org>
> > To: <cayenne-use..bjectstyle.org>
> > Sent: Thursday, November 03, 2005 2:35 AM
> > Subject: Re: intermittent exception
> >
> >
> >
> >> Hmm... The fact that you are not seeing another stack in your logs
> >> with "objectsFromDataRows" in it speaks against my theory, as
> >> internally it would also call "writePropertyDirectly". Don't know
> >> what else can cause it.
> >>
> >> Andrus
> >>
> >>
> >> On Nov 3, 2005, at 10:14 AM, Andrus Adamchik wrote:
> >>
> >>> One possibility to consider though... Do you ever fetch data rows
> >>> or use SQLTemplate and then manually convert rows to Company
> >>> objects via DataContext.objectsFromDataRows(..)? This is where type
> >>> info can get blurry as Cayenne can't match "raw" data row query
> >>> results with the right ExtendedTypes.
> >>>
> >>> In the future we should probably do extra type checking and
> >>> conversions in "objectsFromDataRows" ... but there maybe an easier
> >>> workaround in your case if this is indeed what's causing the
> >>> problem.
> >>>
> >>> Andrus
>
This archive was generated by hypermail 2.0.0 : Thu Nov 03 2005 - 21:21:08 EST