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.
> 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), 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.
Andrus
This archive was generated by hypermail 2.0.0 : Sat Mar 29 2003 - 17:32:42 EST