On Wednesday, May 16, 2001, at 11:46 PM, Fedor Karpelevitch wrote:
> On Wednesday 16 May 2001 16:45, you wrote:
>> Eric Dobbs <[EMAIL PROTECTED]> writes:
>>> 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.
>>
>> Yes, using two interfaces is definitely the Right Thing.
>
> I agree here, but my concern is that if you get into multiple
> inheritance
> thing you can no longer inherit implementation... Something to think
> about
> here....
Yep, inheriting implementation would be nice. So I put all the
functionality for SELECT, INSERT, UPDATE and DELETE together in my
first suggestion. When I was extending that to create Select,
Insert, Update, and Delete objects, my first draft was to make
Query an abstract class and make the others subclasses. Where
there were methods in Query that were inappropriate for Insert, I
would override the inappropriate methods and maybe throw an
exception. The whole point was to be able to inherit
implementation while providing an API that reads well. This
inheritance convenience comes at the expense of having objects
totally specialized to their task.
>>> 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.
>
> sounds good, but see above...
>
>>
>> So we need a Clause interface and a ColumnMap interface (interface
>> names negotiable, just tossing out suggestions).
>
> I am not sure what Clause interface would mean. I do not see what
> different
> clauses have in common....
> And I am not sure what you mean by ColumnMap interface, is that Eric's
> "set
> column"?
I take Dan's suggestion to be names for the two interfaces I suggested.
I think Where interface would be more specific, and maybe ColumnValueMap.
>>
>>>> BTW both Statement & Condition implement SQLCode interface which only
>>>> contains toSQL metod.
>>
>> I really don't like the toSQL() method for a class which implements a
>> SQLCode interface. I would prefer that the standard toString() method
>> be part of the SQLCode interface, and that toString() be used in place
>> of toSQL(). Yes, the returned value *is* plenty readable.
>
> the reason for toSQL is not readablity (I withdrew that one), but these
> two
> things:
>
> 1) if you use toString() you end up with LOTS of String concatenation.
> toSQL
> returns StringStackBuffer instead. look at the code.
> 2) toSQL takes DB as parameter ( sig is toSQL(DBdb)) so it has the
> ability to
> produce DB-specific SQL if needed.
I like both of those reasons. I like being able to pass in a DB object.
I'm not sure StringStackBuffer is the right choice for the return type.
With a StringStackBuffer you can do .toString("/"). That's reasonable to
do with a StringStackBuffer, but not reasonable for the SQL we want out.
I think I would prefer a StringBuffer. In which case I'd prefer a method
named toStringBuffer(DB db).
>>
>>>> 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 frown on the extra objects that will be instantiated unnecessarily,
>
> I do not think I instantiate anything _extra_ here versus method-based
> approach, because in that case you still need to put _some_ object into
> your
> list of conditions, be that Criterion or eanything else. So I think it
> is
> just as bad/good. I do not see any problem with that - objects are
> pretty
> light.
Every place in the API you propose that has new XYZ() is instantiating
an object. By contrast, this latest suggestion I've offered...
> new Comparison().equals(col,val).or().equals(col2,val2)
...the Comparison object is instantiated only once. All of the methods
would modify that Comparison instance and return a reference to it.
The only place where another instance would be created is when nested
groups are needed in the comparison. That might look like this:
new Comparison().equals(col,val).and(
new Comparison().equals(col2,val2).or().equals(col2,val3))
which would create SQL like this:
COL=VAL AND (COL2=VAL2 OR COL2=VAL3)
With your model the equivalent SQL would need something like this:
new And(new Equals(col,val),
new Or(new Equals(col2,val2), new Equals(col2,val3)))
Two instances in the former, four instances in the latter. Instantiating
objects is not light, otherwise there wouldn't be any need for the cool
caching service. I think the methods approach would offer better
performance and I still think it reads better.
>> though the interfaces do make for nice Java code. However, this is
>> code that will be called over and over again, so performance is an
>> issue.
>
> btw in my opinion the better design allows for cleaner reuse of
> Query/Condition objects (they are thread-safe too) so you will be able
> to
> save a lot of the calls etc...
>>
>>> 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[])
>>
>> I am not adverse to this idea. It will certainly perform much better
>> than possibly excessive object instantiation.
>
> again, i am afraid you'll have to create just as many objects. This
> approach,
> however is less flexible. The main reason I made everything an object
> implementing Condition is that And and Or accepts conditions as members
> which
> in turn may be And's and Or's thjis way allowing clean way to create
> conditions of any complexity. Also code duplication is virtual zero.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
