On Friday, April 26, 2002, at 12:24 AM, Sam Joseph wrote:
> Eric Dobbs wrote:
>
>> 1. wish it didn't extend hashtable,
>> would prefer 'has-a' instead of 'is-a'
>
> why?
It is a generally accepted practice to favor
composition over inheritance. Some of my complaints
below are classic examples of why composition is
favored.
I want to change the implementation because I think
hashtable is the wrong tool for the job. But I can't
without possibly breaking existing code which has been
written with the expectation that Criteria 'is-a'
hashtable.
>> 2. wish it wasn't implemented as a hashtable at all,
>> the use of column names for keys means
>> "FOO >= 10 AND FOO < 20" must use a Criterion.
>
> presumably this is only bad because you don't like Criterion
Hashtable is a poor tool for modeling SQL. A Hashtable
is a one-to-one map of keys and values. SQL doesn't
fit that structure. I see Criterion as a symptom that
Hashtable is the wrong tool for the job.
Criteria uses column names for keys. But nested
Criterion can include various column names. So which
column name is the right one for use with the key?
You could surely establish rules and conventions about
how to handle that situation, but the *need* for those
rules is an indication that Hashtable doesn't do what
an SQL statement needs.
>> 3. Criterion is ugly, and I wish client code didn't even know
>> about it.
>
> Ugliness is in the eye of the beholder :-)
Behold!
Item 1. An example from the Criteria HOWTO
Criteria criteria = new Criteria();
criteria.add(InvoicePeer.COST,
1000,
Criteria.GREATER_EQUAL);
Criteria.Criterion criterion =
criteria.getCriterion(InvoicePeer.COST);
criterion.and(
criteria.getNewCriterion(
criterion.getTable(),
criterion.getColumn(),
new Integer(5000),
Criteria.LESS_EQUAL )
);
Item 2. The equivalent SQL:
WHERE INVOICE_COST >= 1000
AND INVOICE_COST <= 5000
I want the Criteria object to be as readable as item 2,
or as close to that as possible within the confines of
Java syntax. The code I proposed last year was
something like this:
Sql sql = SqlFactory.getInstance("MySQL");
String where = sql.where(
sql.and(sql.greaterEqual(INVOICE_COST,1000),
sql.lessEqual(INVOICE_COST,5000) ));
Which is not totally readable, but much better than
what Criteria currently offers.
>> 4. as you have pointed out, queries of modest complexity using
>> nested Criterion have precedence problems (which is why I'm
>> interested in your patch).
>
> This seems to be the only substantial problem no? I mean points 1-3
> are personal preference (at least superficially). As long as the
> appropriate functionality is supported I don't think most users will
> care one way or the other.
>
> Is there a specific functional or maintenance reason why, if Criterion
> was fixed regarding precedence issues, that we would still want to
> replace Criteria/Criterion?
I think those fixes would extend the life of Criteria
a lot, but I'd still want to replace it.
-Eric
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
