On Thursday, May 10, 2001, at 09:34 PM, Fedor Karpelevitch wrote:
> The thing I do not like about you proposal (vs. mine) as well as about
> current Criteria is the fact that you are mixing together different
> things
> which deserve a clear separation. What I mean is that you are using
> Query in
> some context as query ( with all it's attributes ) and in some contexts
> (when
> you pass it to add method) you ignore use only condition part of it and
> ignore other attributes. This makes me feel bad about it. In my
> opinion, when
> you need a condition, you should use a Condition object, when you need a
> query you use a Query etc, etc. Everything should serve it's purpose,
> not
> more or less. And the code you are producing looks not much more like
> SQL
> besides that I do not see why it should. See some more comments
> below....
I agree that my example is not much more like SQL, but I think it
is more readable. More on that below. Both of our suggestions
bear enough resemblance to SQL to make the learning curve somewhat
less steep for those who know SQL but are new to Turbine.
Also, specializing the objects to their specific purposes makes
sense. I like Dan Rall's suggestion about Insert(). And as I
have been thinking about how to implement that suggestion, I see
exactly what you mean about having the objects do only what they
need to do.
What started me on this project is that the existing Criteria
requires an awful lot of fussing with Criteria.Criterion objects
in order to compose any query with an OR in the WHERE clause. I
built my example with the idea that the client code using a Query
object need not know anything about the Criterion, nor should the
client need to know the difference between a simple Criterion and
a CompositeCriteria.
That goal is still compelling to me despite the fact that it is
in conflict with this other goal of having the objects do only
what they absolutely need to do. I think this is an example
where a Facade that combines a few different purposes is
appropriate to reduce the complexity when creating compound
WHERE clauses.
Maybe this scheme would be an acceptable compromise:
Statement
|
|--Select
|--Insert
|--Update
|--Delete
|--Where
Your choice of 'Statement' makes more sense here than my 'Query'.
'Where' would be a facade over the Criteria, Criterion, and
CompositeCriteria and would function like I have outlined. The
others would be specialized Statement objects that do only what's
appropriate for their particular statement. I know that 'Where'
looks a little out of place, but I think it may be appropriate.
I'm open to other ideas. (Hopefully it's clear by now that I'm
not closed-minded about this stuff. 8^)
>> Query q = new Query(Query.SELECT)
>> .addSelectColumn(column1)
>> .addSelectColumn(column2)
>> .addSelectColumn(column3)
>> .addSelectColumn(column4)
>> .where(column1,column3,Query.EQUAL)
>
> just to make sure.. Do you realize that column3 here (which, I think,
> is a
> String) is indistinguishible from a String you'd like to compare
> column1 to?
> i.e. how would you go about:
> .where(column1, "somevalue", Query.EQUAL) ?
This could be handled by a collection of convenience methods like
Criteria does with add().
>> .and(column2,"'foo%'",Query.LIKE)
>
> this is also looks very questionable to me. Why the first condition is
> added
> with where() and all the other ones - with an add(). I do not like two
> functions doing the same thing. It's just plain wrong.
and(), or(), and where() are all convenience methods that do what
your code does with add(). The names of the methods help make
the code more readable. Also, they all do slightly different
things and are not completely redundant.
They could all be replaced by one method like this:
add(TableColumn tc, Object value, String comparison,
String conjunction)
where conjunction is one of " AND ", " OR ", or "".
It would abstract a SQL fragment like this:
" AND TABLE.COLUMN='foo'"
I chose not to do it that way because I think the and(), or()
and where() methods are more clear. This is analogous to
Dan's suggestion that I replace "new Query(INSERT)" with
"new Insert()".
>> .and(new Query()
>> .where(column4,new Integer(1),Query.EQUAL)
>
> now this does not look like SQL at all - would that be :
>
> ... AND (WHERE column4=1 OR ...) ....
>
> not really...
I agree that this isn't parallel with SQL, but it is fairly
readable for someone who knows SQL. And I think it is more
easy to read than this:
new And()
.add(new Equal(column4, 1))
.add(new ...
I just don't think .add(new Or(...)) reads as well as .or(...)
Likewise for .add(new And(...)) vs. .and(...)
Thanks for making this an interesting discussion. I'm sure
whatever we finally agree on will rock.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
