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 : Thu Mar 27 2003 - 19:34:55 EST