I didn't state how a user would configure it, only how it could be
processed if it was specified. Right now, I'm leaning on making
join semantics represent this. So a query can be (inner|outer) +
(split|nosplit). Realistically, that's probably only inner, inner
w/split, and outer w/split as the three options.
Your original idea of "+" and "|" works as part of the path expression
works for me as well.
On 8/20/06, Andrus Adamchik <andru..bjectstyle.org> wrote:
> > Hope this makes sense. I don't feel I'm explaining it very well.
> > It's probably easier to implement than to explain, so I think this
> > will be my next step.
>
> Indeed, I got lost on how a user would configure split vs. no-split.
> Could you post a sample SelectQuery?
>
> Andrus
>
>
>
>
> On Aug 20, 2006, at 4:03 AM, Mike Kienenberger wrote:
>
> > Here's an idea I had for handling splits.
> >
> > Right now, QueryAsembler.dbRelationshipAdded(..) removes "duplicates".
> > If instead we temporarily "overrode" aliases when resolving a split
> > expression, it seems as if this might work without any further
> > changes.
> >
> > Going back to my standard example:
> >
> > SELECT * FROM (SELECT [...] FROM
> >
> > ENG_WORK_MGMT.FEE t0,
> > ENG_WORK_MGMT.FEE_TYPE t1,
> > ENG_WORK_MGMT.FEE_CYCLE
> > ENG_WORK_MGMT.AUTHORIZATION_DOCUMENT t3,
> > ENG_WORK_MGMT.PERMIT_DOCUMENT t4,
> > ENG_WORK_MGMT.AUTHORIZATION_DOCUMENT t5
> >
> > WHERE
> > t0.FEE_TYPE_ID = t1.FEE_TYPE_ID
> > AND t0.FEE_ID = t2.FEE_CYCLE_ID
> > AND t2.FEE_CYCLE_ID = t3.INITIAL_FEE_CYCLE_ID(+)
> > AND t3.AUTHORIZATION_DOCUMENT_ID = t4.PERMIT_DOCUMENT_ID(+)
> > AND t2.FEE_CYCLE_ID = t5.RECURRING_FEE_CYCLE_ID(+)
> >
> > AND ((t1.DESCRIPTION = ?)
> > AND ((t4.AGENCY_ID = ?)
> > OR (t4.AGENCY_ID = ?))))
> >
> > We start off with an alias table
> >
> > FEE = t0
> > FEE_TYPE = t1
> > FEE_CYLE = t2
> >
> > Now we process an expression with a split
> >
> > AUTHORIZATION_DOCUMENT = t3
> > PERMIT_DOCUMENT = t4
> >
> > the split expression ends, so we revert these two values.
> >
> > Next expression with a split gives us
> >
> > AUTHORIZATION_DOCUMENT = t5
> > PERMIT_DOCUMENT = t6
> >
> > And these are again reverted in the alias table when the split
> > expression ends.
> >
> > The reason I say reverted is that there may be regular inner joins
> > (non-split) against these same tables. My example doesn't really
> > show that off well.
> >
> > Assume there's another AUTHORIZATION_DOCUMENT.date = yyyy-mm-dd phrase
> > that is an inner join. It already exists as an alias of
> > AUTHORIZATION_DOCUMENT = t2Point5, so we want this to still be back in
> > the alias table as soon as we are no longer processing the split.
> >
> > Hope this makes sense. I don't feel I'm explaining it very well.
> > It's probably easier to implement than to explain, so I think this
> > will be my next step.
> >
>
>
This archive was generated by hypermail 2.0.0 : Sun Aug 20 2006 - 14:33:02 EDT