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 Thu, 19 Apr 2012 08:24:10 GMT
> I can live with this... but I'm with Thomas V in that Object parameters
> are "not a good thing".  But this is balanced by "ease of use"...
>
> One question I have about just using Object is... how to you handle
String
> Objects... are they a table name or constant?  The current methods
> make it clear
> that a string is a column name.

The extra String methods would be removed.
Strings on the lhs would be handled as objects not as columns.
And Column objects on the RHS would be handled as columns not as Objects...
The String semantics would be described in the javadoc of the method and
there would be a big note in the migration guide to point developers to
that change.

> My first thoughts on how to resolve these is to create a "SQLExpression"
> Interface that simply requires a getSQLExpression() method, have Column
> Extend this and have simple implementation that has an Object constructor
and
> return the Object.toString() results via the getSQLExpression method..

It is a bit more difficult than that
- The "lhs Object" soultions would also allow subselects on the lhs, which
is not easily possible with your suggestion
- Ignoring case needs a special treatment, which is now handled centrally
and might have effects on more than the rendered value (e.g. on the value
on the other side of the operator)
- Also the question remains how to handle this in Criterion (Object lhs ?
More than one field for the lhs ?)

Note that we already have the "lhs Object" solution for the rhs, so the
"lhs Object" solution would just be treating lhs and rhs the same (the code
would reflect this same treatment, so the code will not become more
complicated).

> Takes a little more code to use non-column RHS, e.g. add(new
> SimpleSQLExpression(0),...
> but this is a rare usage case...
> Since using String column names is a common convenience case, maybe it
should
> Be:
>
>   and(String column, Object value)
>   and(SQLExpression column, Object value)
>   and(String column, Object value, SqlEnum comparison)
>   and(SQLExpression column, Object value, SqlEnum comparison)
>
> Doesn't simplify the methods, but does a better job of type checking and
> keeps the common case of string column names easy to use.
>
> If we do go with a RHS Object signature, the javadocs should be
> clear about what
> is expected of this object (toString() to generate allowable RHS SQL
value).

Sure.

   Thomas

> -----Original Message-----
> From: Thomas Fox [mailto:Thomas.Fox@seitenbau.net]
> Sent: Monday, April 16, 2012 11:59 PM
> To: Apache Torque Developers List
> Subject: Re: Criterions which do not reference a column
>
> Independent of the ongoing discussion about whether to generify
> Criterions or not, does anybody object against the orogonal poposal
> for changing the criteria.Criteria interface from
>
>   and(String column, Object value)
>   and(Column column, Object value)
>   and(String column, Object value, SqlEnum comparison)
>   and(Column column, Object value, SqlEnum comparison) to
>   and (Object lhs, Object rhs)
>   and (Object lhs, Object rhs, SqlEnum comparison) (same for or,
> where, andIn, ..., the util.Criteria interface would stay as
> is)
>
> as a solution for TORQUE-185 (also resulting in Criterion changes,
> lhs and rhs are Objects in Criterion) ?
>
> If this interface needs to be changed again as a result from the
> "generify Criterions" discussions, I'll implement that change if it
> has been decided.
>
> I'll implement it in a few days if there are no objections.
>
>    Thomas
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>
> DukeCE Privacy Statement:
> Please be advised that this e-mail and any files transmitted with
> it are confidential communication or may otherwise be privileged or
> confidential and are intended solely for the individual or entity
> to whom they are addressed. If you are not the intended recipient
> you may not rely on the contents of this email or any attachments,
> and we ask that you please not read, copy or retransmit this
> communication, but reply to the sender and destroy the email, its
> contents, and all copies thereof immediately. Any unauthorized
> dissemination, distribution or copying of this communication is
> strictly prohibited.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: torque-dev-help@db.apache.org
>


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


Mime
View raw message