On Wednesday, May 30, 2001, at 09:16 AM, Florian Lindauer wrote:
> After a (meanwhile deeper) look in Criteria/Criterion, I came
> to the conclusion, that the whole Criteria/Criterion-concept
> does not allow real general and/or-nestings.
> Every criterion holds one condition. con/disjunctions are
> achieved by building two chains: and and or, to other criterions.
> As there is no natural precedence between the and and the
> or-link, it is done randomly (actually first or, then and),
> leading to the above effect.
That is a correct and well described assessment of the problem,
but I'll just add reference to specific code and elaborate a bit.
Hopefully the details I've added below will help everyone
interested in the problem find the offending code.
The SQL where clause is constructed in Criteria.Criterion's
appendTo(StringBuffer) method. At the end of that method the
attached criterion, 'and' and 'or', are .append()ed in turn. If
just an 'and' is attached the SQL would be fine, same for just an
'or'. But if both are present, the or part comes first, which is
not appropriate in all cases. You put it more succinctly: "there
is no natural precedence between the and and the or-link".
I think the primary problem is in the structure of the Criterion
object. There is a need to abstract the connecting conjunctions
and to control the placement of parentheses. The current means
of abstracting those is to hold two pointers, one for 'and' and
one for 'or'. As you have nicely pointed out, there's no way
to control the predidence.
I started a discussion about the very subject in the developer's
list earlier this year. That proposal has grown considerably in
scope and I don't expect it to be resolved any time soon. You
can read the thread in the mail archive:
http://www.mail-archive.com/turbine-dev%40jakarta.apache.org/
search for [PROPOSAL] criterion, and skip the items about
deprecation.
I appreciate that you have attempted to make your changes without
breaking existing code. But I think your solution makes an
already ugly situation more so. Please don't take that wrong.
My primary objection is to the existing code. I would prefer to
deprecate the existing methods and replace them with a better (or
at least less ugly) solution.
I think the specific problem you raise calls for an interim
solution not unlike my original proposal. Specifically, I
suggested that the Criterion object be reimplemented using a
Composite pattern. I further think that the whole implementation
should be hidden behind facade methods in Criteria. The .and()
and .or() methods recently added to Criteria are a step in the
right direction. In the thread I mentioned above, I attached
incomplete but functional sample code which you can get here:
http://www.mail-archive.com/[email protected]/msg00023.html
What do you think of that?
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
