I would prefer to construct the API for a new query so that it
more closely resembles the structure of SQL. This seems much
more readable than what you have proposed:
Query q = new Query()
.addSelectColumn(tableColumn1)
.addSelectColumn(tableColumn2)
.addSelectColumn(tableColumn3)
// the FROM clause can be derived from the SelectColumns and the
// WHERE clause below
.where(tableColumn4,value,comparison)
.and(tableColumn4,value,comparison)
.or(tableColumn4,value,comparison,ignoreCase)
.orderBy(tableColumn2)
.groupBy(tableColumn3);
In the case of arbitrarily complicated where clauses:
Query q1 = new Query()
.where(tableColumn4,value,comparison)
.and(tableColumn4,value,comparison);
Query q2 = new Query()
.where(tableColumn4,value,comparison)
.and(tableColumn4,value,comparison);
Query q = new Query()
.where(q1)
.or(q2);
Or if you prefer:
Query q = new Query()
.where( new Query()
.where(tableColumn4,value,comparison)
.and(tableColumn4,value,comparison))
.or(new Query()
.where(tableColumn4,value,comparison)
.and(tableColumn4,value,comparison));
//Delete clauses need only the where clause
Query q = new Query()
.where(tableColumn1,value,comparison)
.and(tableColumn2,value,comparison)
...
//Update clauses need column-value pairs and an optional where clause
Query q = new Query()
.setColumn(tableColumn1,value1)
.setColumn(tableColumn2,value2)
.setColumn(tableColumn3,value3)
.where(tableColumn4,value,comparison)
.and(tableColumn4,value,comparison);
//Insert clauses need only column-value pairs
Query q = new Query()
.setColumn(tableColumn1,value1)
.setColumn(tableColumn2,value2)
.setColumn();
I am working on some example code to implement the above which I
will send soon for comparison and discussion. I would definitely
like to cooperate on this effort to replace the existing Criteria.
-Eric
On Wednesday, May 9, 2001, at 02:02 AM, Fedor Karpelevitch wrote:
> Hi!
>
> here is the deal:
>
> Latest activity around Criteria inspired me to try to reimplement the
> whole
> idea. I drafted some code which i will check in shortly into
> proposals/fedor/nqm (the code is not going to compile, it's just draft)
>
> The basic idea is to refactor & rename everything to make it more OO,
> solve
> problems Criteria has hard time with, make code duplication virtual
> zero and
> make it flexible enough to be able to adopt future needs.
>
> here is how it breaks down:
>
> the select criteria or conditions are all represented by Condition
> interface
> (it is similar to current Criterion)
>
> the class hierarchy of Conditions looks like this:
>
> Condition
> |
> |----> Comaprison ----> Equal, NotEqual, More, Less etc...
> |
> |-----> ComplexCondition ----> And, Or
>
> (Yes, I know "ComplexCondition" sounds very medical, go ahead and
> suggest a
> better name)
I would prefer to use "CompositeCondition" but that terminology
implies a specific design pattern (see _Design_Patterns_ Composite).
The example code I sent last week shows an example of how I think
that pattern applies the problem of logical operations in Criterion.
I don't like using objects for the logical operators because
it clutters the code with constructors, as shown in your
examples.
> so when you need to get SQL like this:
>
> WHERE A.B=3 AND A.C>5
>
> you'd create the Condition like this:
>
> new And().add(new Equal("A.B", 3)).add(new More("A.C", 5);
>
> if you need smth more complex (pain with Criteria):
>
> WHERE (A.B = 5 and A.C=7) or (A.B=7 and A.C = 15)
>
> is done like this:
>
> new Or()
> .add(new And()
> .add(new Equal("A.B", 5))
> .add(new Equal("A.C", 7)))
> .add(new And()
> .add(new Equal("A.B", 7))
> .add(new Equal("A.C", 15)));
>
>
> uff... hope you won't have to do that, but at least it does not require
> any
> nasty hacks and does not take a lot of extra code....
>
> now, that's just WHERE clause, but for a sql query we need a little
> more like
> select columns, orderby's etc... For that there is Query object which if
> functionally is Criteria less Conditions.
>
> The inheritance here looks like this:
>
> Statement
> |
> |-----> Query
> |
> |-----> Update
> |
> |-----> Delete
>
> Statement provides common stuff like WHERE and FROM clause.
> Query also has methods like addSelectColumn, addOrderByColumn etc...
>
> So I am asking for comments/ideas/money ... sorry, no money.
> And I propose this as a replacement to current Criteria and related
> classes.
> Appropriate methods should be added to Peers & OM which would take
> Condition
> or Query instead of Criteria. At the point when it's fully functional &
> stable Criteria & corresponding Peer methods would be deprecated and at
> some
> point removed.
>
> Also couple of smaller points: I think those new classes should go into
> their
> own package at least to make it clear where the new stuff is and where
> is the
> old one. What do you, guys, think? Also any ideas for the name of the
> package
> - the best I could come up with is "nqm", which I do not like...
>
> Fedor.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
