I think a simple solution can be implemented. With the proposals
currently in the works I do not see a reason to completely redesign
Criteria. How about a flag to note which method was called first then
that condition will be given the higher priority? I think that would be
fairly intuitive, though I have not used the new convenience methods and
do not know if it is as workable/intuitive as I imagine.
john mcnally
Eric Dobbs wrote:
>
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
