Hi Patrick -
> > (a) Timeline: "Slow going". I can work on my commute (Munich S-Bahn,
> about 45 minutes/direction = 90 minutes/day).
>
> It's no problem. We'll get things in there at some point. I just
> hope that you'll have the persistence to make it through it all. :)
Definitely: (a) We want to use NHib 3.x behind RIA-Services - and therefore we
need NHib.Linq in a quite critical commercial project. (b) I don't give up that
fast :-).
> It seems like a tricky problem.
Tricky ... well: I think it is, in some sense, actually easy (see below) -
after all, we already did "it" ("all logical operators to HQL") here in our
project. See below.
>
> > (b) No, no tests for self joins. I'll add them in the evening.
> >
I did in NH-2583c.diff (but I forgot to Update before creating the patch - I'll
check whether I have to create a new one).
> > BUT!!!!!!!!!!!!
> >
> > (c) De Morgan allows us to "write an || with &&": A || B is the same as
> !(!A && !B). Although it is not clear that this is also true under the
> "navigational logic extension of ||",
Actually, de Morgan holds. I'll put that in an extension to the "semantics and
design text" ... somewhen.
> > (d) 2 more testcases I wrote with ||s of depth 3 fail. I have to look
> ...
Corrected - dumb bug - see NH-2583c.diff.
>
> I have to say I'm a bit concerned that there are apparently a number
> of edge cases and unhandled situations. This may be completely
> meaningless, but my feeling is that there is simplicity around the
> corner if we look at the problem in a slightly different way.
Here is why I think the problem is simple: A correct solution is to
* replace each and every navigational chain (at depth > 1) a.B.C.... with an
outer join;
* add existence guards to each and every simple condition
* use a sub-select for the Any operator (and other set operators if they are to
be supported; joins remain local to the sub-selects).
That's it. Nothing more. "I leave the proof as an exercise ..." etc. This is
just my "(||-5) semantics" (its description is still missing the Any part).
The problems arise from:
(a) the optimizations A and B. They are not necessary for correctness, but the
examples show that the selects get much smaller with them. And unfortunately,
moving information over the tree for the optimization(s) is work. Also, the
re-linq visitors are quite good, but not perfect (for me - I now define
visitors usually semewhat like
interface Visitor<T> {
... VisitA(A a, T parameter);
... VisitB(B b, T parameter);
...
}
The additional free parameter T helps quite a lot to write simple "attributed
grammar visitors", where one transports information locally. But this is as it
is ...).
(b) from my (not [yet]) understanding the existing code;
(c) from ... well ... limitations when programming (for example, I just
overlooked the ! operator. A colleague who follows my work remarked that in the
code in our framework here, there is a _belowNot flag in the "condition
visitor" - "guess why").
> > (e) I'm worried about the Any operator. I have not yet written tests for
> it, but I fear that "it doesn't work at all" (if the condition inside has
> navigations + ||s). I fear that this cannot be solved with Linq rewriting,
> but rather requires changes to the HQL generator (create OUTER JOINs for
> subselects???).
>
> Well, if changes are needed, we can make them. I think few people
> would complain about enhanced capabilities in hql anyways. Perhaps
> some of this has already been implemented in Hibernate.
Let's first get the || / && / ! running correctly - then we take on the Any.
I'll take a look now into that VisitSelect/Order vs. VisitWhere issue ...
Regards
Harald
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone
