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 - 18:14:05 EST