db-torque-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Fox <Thomas....@seitenbau.net>
Subject Re: Criterions which do not reference a column
Date Tue, 24 Apr 2012 12:14:14 GMT
Thomas Vandahl write

> On 12.04.12 05:02, Thomas Fox wrote:
> > ...
> > I am also of the opinion that the benefits of using a container on
> > left/right side (better type checking) are more than outweighed by the
> > comlpicated use it causes (having to write new Criterion(new Container
> > new Container(subqueryCriteria)) in the above case). Because of this,
> > a container is not an option IMHO.
> I thought of having some kind of container internally, not exposing it
> to the interface, so that and(StringColumn, Criteria) as well as
> and(ColumnObject Object) can work with at least some type checking.

I have looked again at the code and did not have any idea how to improve
type checking.
In Criteria, it would bloat the interface too much: add(Column, Column),
add(Long, Column), add(Column, Long) etc...
As to write an internal wrapper, the to which problem I surrendered was
that not only types need to be considered, also operators and ignoreCase
need all to be checked.
e.g. if the lhs is a column and the rhs is a String and ignore case is on,
then the rendered sql for the lhs is different than if the rhs is an int
(because an int cannot be ignorecased). On the other hand, this could also
be a "type check", e.g. an int is not allowed if ignoreCase is true... I do
not know where to put the limit.

The best thing I could come up with is to create extra classes for the
different rendering strategies. There is a standard strategy at the end of
the list which "takes all the rest" but one could also think of cheking
there for allowed values, But I do not know whether this would be good
because this requires a lot of knowledge about what is allowed in the db
drivers (which handle the prepared statement replacements)

> > So, though I do not doubt that the Criterion object can be generified,
> > still do not see the benefits of doing it.
> Well, I think that the Torque API is not very type-safe as it is (the
> fact that Date objects are supported in Criteria but Calendar objects
> are not is not documented, for example).

In Torque 4 it depends on the DB driver whether it can handle Calendar
objects... no idea whether they do or not...
> I would like to improve this.

As above, I cannot see how. At least, for the calendar example, now the db
driver would (hopefully) complain about a wrong object type...

> ...

I have now committed a suggestion on how this could look like. Suggestions
for improvements are very welcome.


To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org

View raw message