On Friday 11 May 2001 08:22, you wrote:
> 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.
I do not see why it should resemble SQL. I'd rather argue that it should
resemble good Java code :-)
>
> 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.
if you remember, I was suggesting Insert, Update etc.. objects too. I am
pretty sure that Update, Delete & Query should extend Statement (or other
common class) since they have something in common - they all (may) have WHERE
& FROM. Insert is not like that so I am not sure it should be a Statement.
Another option is smth. like this:
Statement
|
|---->CriteriaStatement----->Query, Update, Delete
|
|---->Insert
what I am sure about is that WHERE does not belong here. It's not a
statement, just a clause. And "Where" is nothing by itself - it's just
top-level Condition.
BTW both Statement & Condition implement SQLCode interface which only
contains toSQL metod.
>
> 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.
here is how I would implement this in my model:
add methods
public And and(Condition)
&
public Or or(Condition)
to the interface Condition. This allows you to do:
new Equal(col1,val1)
.and(new Equal(col2.val2))
.add(new More(col3, val3))
which would finally produce an And object.
one part here which I am not sure about is unclear semantics of And.or() and
OR.and() methods, i.e. what should be result of:
new Equal(col1,val1)
.or(new Equal(col2.val2))
.and(new More(col3, val3))
its not obvious to me what this should mean either:
1. (col1 = val1 OR col2=val2) AND col3 > val3
2. col1 = val1 OR (col2=val2 AND col3 > val3)
#1 make a bitmore sense to me...
>
> 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.
well. I do not like "convinience" for the price of clean design... I do not
see convinience anyways...
>
> 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(...)
i think adding .and() and .or() methods as described above will make you
happy?
> Thanks for making this an interesting discussion. I'm sure
> whatever we finally agree on will rock.
that's for sure :-)
Fedor.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
