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....
> > 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"?
>
> > > 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 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.
> 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.
dixi.
Fedor.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
