On 8/17/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > One thing that is going to be annoying is having to specify an outer
> > join for every expression. I'm thinking we could have an "effective
> > outer join" value which, if not specified on the current Expression,
> > inherits from the parent expression. So an Expression join type by
> > default would be "unspecified" which means ask the parent. Any root
> > expression with unspecified would default to an inner join.
>
> That's where I disagree - when you build a query, every outer join is
> unique and unrelated to anything else. What I was thinking we can do
> to simplify the semantics specification (and also make expressions
> parsed from strings work the same way as expressions created via
> ExpressionFactory) is add join type to the object path string. E.g.
> use a "+" sign like Oracle did in the past:
>
> * Inner join: "toArtist"
> * Left outer join: "toArtist+"
> * Longer path with mixed joins: "toGallery+.toAddress"
>
> This seems like a reasonable non-verbose solution. What do you think?
Seems reasonable. Is this sufficient for many-to-many join tables?
Ie, if we have a Obj toBList relationship, will "toBList+"
automatically translate into "where a.a_id = bjointable.a_id(+) and
bjointable.b_id = b.b_id(+)"?
You'd think I'd know the answer (or be implementing it) since I'm
looking right at QueryAssemblyHelper.appendObjPath(), but I'm not sure
:-)
It seems like we now would have one Expression supporting multiple
join types, depending on the path expression.
resolvePathComponents would have to return not only the
ObjRelationship/ObjAttributes, but also whether each piece was an
outer join.
This archive was generated by hypermail 2.0.0 : Thu Aug 17 2006 - 17:04:59 EDT