+1 on using a chained query builder similar to that for Ruby/Rails.
> Am I the only one that finds andQualifier(Expression),
> orQualifier(Expression), setQualifier(Expression),
> and Expression getQualifier() to be odd?
As an application developer, I'd find either far too verbose. I want something
where I know from context what I'm talking about, because I'm typically writing
a heap of conditions, so it's enough to write it once.
E.g. it could be
new QualifierList ()
.like("name", "b%")
.or (new QualifierList ()
.greater("age", 23)
.less("age", 27)
)
The QualifierList constructor and the first qualifier can be merged into one if
writing a small subclass of QualifierList is in order:
class Greater extends QualifierList {
Greater(String property, int value) {
super ();
this.greater(property, value);
}
}
giving
new QualifierList ()
.like("name", "b%")
.or (
new Greater("age", 23)
.less("age", 27)
)
The same technique could be applied to Aristedes' example:
SelectQuery(Artist.class)
.like("name", "b%")
.or (
new Greater("age", 23)
.less("age", 27)
)
.join(Gallery.class)
.limit(10)
.order(Artist.name)
.perform()
.like, .or, .greater, .less would then delegate to SelectQuery's member
QualifierList whereConditions
(which would need to be merged using AND when generating SQL)
Note that these are still Expressions, not Qualifiers, since the lists can
exist independently of a query.
In fact it makes a lot of sense; SQL conditions for a table might be reused
across queries. (Yes I know this is usually done via RDBMS views.
Unfortunately, at least Oracle is extremely poor at providing key and column
metadata for views.)
Just providing data points :-)
Regards,
Jo
