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: Change semantics of Criteria.add() and Criteria.or()
Date Mon, 12 Dec 2011 14:07:44 GMT
> > I propose to change the behaviour of the  Criteria.add() and
> > methods to the intuitive behaviour stated above in Torque 4. (I have
> > to many bugs at $work resulting from the counter-intuitive behaviour).
> > Any objections ?
> I wholeheartedly agree to your proposal. However this will break
> existing code. The old code would compile but do soemthing different. Do
> we have a warning sign big enough to show it to everybody? Or is there
> some way to create a method signature that leads to a compile error then?

Technically, we could do the following

1) deprecate or remove the existing class and create a new one. Variants:
1a) move the new class to a new package
1b) rename the class (but I do not have a good new name and many OR Mappers
use the name Criteria)

2) deprecate the existing methods and create new ones. We could
deprecate/remove the add methods and tell the user to use the and methods.
But I do not have a good new name for the "or" methods.

3) Because of TORQUE-168, new methods have been added which use a Column
object as column name. Until now, Strings have been used as column name. We
could deprecate/remove the methods which use String values. This means that
people which do NOT use the constants from the Peer classes have more work.

4) Major version change is warning sign enough

Personally I am not sure what to suggest. Criteria is a very big class and
removing methods is a good thing IMHO, so deprecating the add methods and
deprecating the methods which use Strings ( 2) + 3) ) should be ok as
warning signs. 4) is also fine with me. But I am open to other suggestions.


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

View raw message