On Sat, 29 Mar 2003, Andrus Adamchik wrote:
> On Saturday, March 29, 2003, at 04:00 AM, Craig Miskell wrote:
> >
> > Turns out that my chosen approach isn't so good afterall.. the
> > "unforseen
> > problem" was that DataContext.objectFromDataRow (ultimately called
> > after
> > fetch has occurred) uses an ObjectId constructed from the DataRow to
> > find
> > the hollow object in the object store. Because the FaultObjectId is
> > something completely different, it doesn't find the hollow object, so
> > creates a new one. Bad karma results.
>
> Craig,
>
> I wonder if we can still do something about it. How about
> "objectFromDataRow" will *always* return a fault if an id in question
> is a "FaultObjectId"? Then the object will stay a fault until someone
> accesses its properties. Then DataContext.refetchObject() will be
> invoked, and it should handle building the right query.
Unfortunately all objectFromDataRow gets is an ObjEntity and a data row
(Map). At that stage, it has no idea what caused the fetch (indeed,
there's no requirement for it to have been a fetch at all). It then
constructs an objectid from the data row and uses that to find the
existing object or create a new one. Because that object id doesn't match
the "FaultObjectId", a new object gets created.
>
>
> > Looks like it has to be the first option, as the only alternative I can
> > see consists of creating a new query subclass and tweaking
> > ContextSelectObserver to handle that query differently... that strikes
> > me
> > as particularly ugly.
>
> Yeah, creating specialized queries looks like a bad idea (our current
> FlattenedRelationship*Query always looked a bit of kludge to me, though
> I haven't looked into that in details),
It worked at the time, but I harbour similar reservations now. Well worth
looking at later I think.
> besides doing an extra 1..*
> joins is not very exciting either. Oh well ... If the option above
> doesn't work I'd investigate using regular select query with prefetches
> specified, and a specialized Observer, this way we may solve two
> problems at once. Lets discuss this in case if this becomes our last
> option.
Oooo, just had another look...refetchObject creates the query and then
calls performQuery(query) which uses standard observers. We could instead
create a custom observer (kind of as suggested above, perhaps even an
inner class) which knows how to handle this sort of fetch properly, and
use the other performQuery methods which take an observer.
Will let y'all know how it goes,
Craig
This archive was generated by hypermail 2.0.0 : Sat Mar 29 2003 - 21:19:08 EST