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.
> 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.
So we need a Clause interface and a ColumnMap interface (interface
names negotiable, just tossing out suggestions).
> > 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.
> > 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,
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.
> 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.
> 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.
Fedor, thoughts?
Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
