On 8/17/06, Andrus Adamchik <[EMAIL PROTECTED]> 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.
