"Bother", said Pooh.
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.
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.
Andrus: Any hints? You've apparently thought at least vaguely about
it...
Thanks,
Craig
On Fri, 28 Mar 2003, Craig Miskell wrote:
> In that case, pending any other feedback, I think I'll go with the
> second option. I was a little hesitant to subclass ObjectId initially,
> but if you think it's ok, then I'll head that way.
>
> Onward.....
>
> Craig
>
> On Fri, 2003-03-28 at 11:14, Andrus Adamchik wrote:
> > First option (prefetching corp unit id) is actuallly nice to have for
> > another feature - prefetching in queries. I was planning to add support
> > for that ~1.1. This indeed seems like lots of work and testing.
> >
> > As for the second option, it seems like you will need some ObjectId tricks
> > for the destination to-one fault (HOLLOW) object. One way would be to
> > subclass ObjectId (FaultObjectId or something) to support a different
> > object read approach in DataContext.refetchObject().
> >
> > This is very raw, but I have something like that in mind:
> >
> > FaultObjectId extends ObjectId {
> > // encapsulate the first join table id
> > protected ObjectId startId;
> >
> > // DB_PATH
> > protected String relationshipPath;
> >
> > public Map getIdSnapshot() {
> > return Collections.EMPTY_MAP;
> > }
> >
> > // not sure how this sould work
> > public boolean isTemporary() {
> > return true;
> > }
> > }
> >
> > Of course I left out too many details, so there might be unexpected
> > problems...
> >
> > Andrus
> >
> > > Example relationship... CorporateUnit has many Departments, which have
> > > many Employees. Employee has a flattened relationship
> > > toDept->toCorporateUnit to get directly to it's Corporate unit
> > >
> > > I have two options, both of which require significant munging at
> > > different places, and it boils down to expectation. Would you (or other
> > > users) expect that when the Employee in the above example is fetched,
> > > that cayenne would do a join with Department in order to find the
> > > CorporateUnit id (internally creating a hollow CorporateUnit object with
> > > the fetched id), or would you expect that just Employee attributes are
> > > fetched, and the join only occurs when the CorporateUnit is touched
> > > (somehow having encoded the source of the department in the Objectid
> > > maybe... ).
> > >
> > > Both cause as much pain: the first requires futzing with
> > > ResultIterator/Descriptor etc to ensure that column names can be
> > > distinguished (the id of the Dept would need to be part of the results);
> > > the second requires munging with ObjectId or something equally
> > > horrendous. Plus there's the issue of expectations and performance (some
> > > would say the join shouldn't happen until the user explicitly requests
> > > it, others might say it's worth the hit because you're already fetching
> > > the employee).
> > >
> > > Any and all feedback gratefully received :-) (including that which tells
> > > me I'm a plonker and there's an easier way)
> > >
> > > Craig
> >
> >
> >
>
>
>
This archive was generated by hypermail 2.0.0 : Sat Mar 29 2003 - 04:04:38 EST