On Saturday, May 12, 2001, at 12:36 AM, Fedor Karpelevitch wrote:
> I do not see why it should resemble SQL. I'd rather argue that it should
> resemble good Java code :-)
Fair enough.
> 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:
Select, Update and Delete all have a where clause in common, but
Insert and Update both have a need to set columns to values, so
I think they belong together too. Particularly because I think
there is a need to support "INSERT OR UPDATE ...".
So maybe we need to create two interfaces here -- one that defines
methods related to the where clause, and one that defines methods
related to assigning values to columns.
Select, and Delete would implement only the "where" interface.
Update would implement both "where" and "set column" interfaces.
Insert would implement only the "set column" interface. I don't
know how to name those interfaces.
> 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.
Okay. I'll let go of that one.
> 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...
It seems to me there needs to be a way to explicitly
group the logical operations. In my model I was using
.where() for that. The .and() and .or() methods
append criteria to the existing group. A new Query()
was used to create any subgroups that could be nested
inside an exiting group. Not quite as elegant as I
would like, but it did prevent the ambiguity you describe
above.
[snip]
> i think adding .and() and .or() methods as described above will make you
> happy?
Not yet. I think what is bothering me about this model
is the use of objects to represent the comparisons. I
don't think an equals operator should be represented as
an object unto itself. Same for the rest of the logical
comparison operators.
I'm thinking of another alternative that would use
methods instead of objects. Like these: .equals(col,val),
.greaterThan(col,val), .in(col,val[]), .notIn(col,val[])
Another thought is that .and() and .or() should not take
any arguments, but just set a connecting string in the
object. So you'd end up with an api like this:
new Comparison().equals(col,val).or().equals(col2,val2)
I'm not sure yet how to handle grouping, yet.
-Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
