Mailing-List: contact torque-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Torque Developers List" <torque-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: domain of greg.monroe@dukece.com
 designates 67.202.195.198 as permitted sender)
From: Greg Monroe <Greg.Monroe@dukece.com>
To: Apache Torque Developers List <torque-dev@db.apache.org>
Date: Mon, 12 Dec 2011 14:16:01 -0500
Subject: RE: Change semantics of Criteria.add() and Criteria.or()
Thread-Topic: Change semantics of Criteria.add() and Criteria.or()
Thread-Index: Acy45yZzJ2MFsDaASieTAI9MOHg2igAB/5Dw
Message-ID: 
 <55B8568AFA5F144F886F18186BAD5B2C2BEC7C1841@durham-e2k7mb1.dukece.com>
References: 
 <OFC7FA947A.C74689DF-ONC1257963.0067B77A-C1257963.00687CFC@seitenbau.net>
 <4EE60173.5030101@apache.org>
 <OF253385DF.130C85B2-ONC1257964.004A6C63-C1257964.004D9D88@seitenbau.net>
 <4EE624D9.10406@apache.org>
In-Reply-To: <4EE624D9.10406@apache.org>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"

Moving Critia to another package is good=2E  I never thought it was a "util=
"=2E=0D=0A=0D=0A+1=0D=0A=0D=0ASome thoughts on implementation:=0D=0A=0D=0AS=
hould we move to a "factory" model that allows for both old and new to exis=
t?=0D=0AE=2Eg=2E Criteria becomes an abstract class and to get on you need =
to call =0D=0ACriterial=2EnewCriteria();  With a setting that allows for ge=
tting old or new =0D=0AVersions of Criteria implimentations=2E=2E=2E=0D=0A=
=0D=0Abut this might be too messy with all method stubs  in the abstract an=
d possibly =0D=0Arequiring class casting in places=2E=0D=0A=0D=0ASince we'r=
e talking about major changes, here are some thoughts on method names=2E=2E=
=2E=0D=0A=0D=0AFirst, I think we've overloaded "add" too much=2E  There are=
 something like 15 =0D=0Aadd methods and 15+ addXXX methods=2E  These relat=
e to widely different parts of =0D=0Athe statement=2E=2E like addJoin(), ad=
dAlias(), etc=2E  I think it would be nice to =0D=0Arefactor these to allow=
 for easier identification and selection by using the =0D=0Aquery area they=
 apply to=2E  So instead of "add" how about "where" as the base =0D=0Afor W=
HERE clause section of a query=2E=0D=0A=0D=0AHere's some example pseudo cod=
e:=0D=0A=0D=0A/* SQL logical flags a=2Ela SqlEnum used below */=0D=0APublic=
 Class SqlLogical {=0D=0A  Public static final SqlLogical AND =3D new SqlLo=
gical("AND");=0D=0A  Public static final SqlLogical OR =3D new SqlLogical("=
OR");=0D=0A  Public static final SqlLogical AND_NOT =3D new SqlLogica("AND =
NOT");=0D=0A  Public static final SqlLogical OR_NOT =3D new SqlLogica("OR N=
OT");=0D=0A=0D=0A/** =0D=0A * Base condition method that all "convenience m=
ethods built on"=0D=0A *=0D=0A * @arg col Column object to use for comparis=
on=0D=0A * @arg value Value to compare with=0D=0A * @arg comparison Type of=
 comparison to make=0D=0A * @arg logical Logical conditions to use with cla=
use (null =3D ADD)=0D=0A */=0D=0APublic Criteria where( Column col, Object =
value, SqlEnum comparison, =0D=0A                       SqlLogical logical =
);=0D=0A=0D=0AMy preference for "convenience" where methods would be to jus=
t have =0D=0Atype specific values and keep all the other options=2E  E=2Eg=
=2E=0D=0A=0D=0APublic Criteria where( Column col, int value, SqlEnum compar=
ison, =0D=0A                       Boolean useOr, Boolean useNot );=0D=0A=
=0D=0AThis would cut way back on the number of methods in criteria by allow=
ing=0D=0Aa lot of "combination" methods to be eliminated=2E=0D=0A=0D=0AProb=
ably the biggest complaint for this is the "readability" of it=2E  E=2Eg=2E=
:=0D=0A=0D=0Ac=2Eadd(USERS=2ECOL_ID, 1, SqlEnum=2EGREATER_THAN )=0D=0A =2Ea=
dd(USERS=2ENAME, "admin%", SqlEnum=2ELIKE)=0D=0A =2EaddNotIn(USERS=2ERIGHTS=
, rightsArray);=0D=0A =0D=0Abecomes=0D=0Ac=2Ewhere(USERS=2ECOL_ID, 1, SqlEn=
um=2EGREATER_THAN, null )=0D=0A =2Ewhere(USERS=2ENAME, "%admin%", SqlEnum=
=2ELIKE, null ),=0D=0A =2Ewhere(USERS=2ERIGHTS, rightsArray, SqlEnum=2EIN, =
SqlLogical=2EAND_NOT);=0D=0A=0D=0APersonally, I like the simplicity of fewe=
r methods to remember and the =0D=0Aresulting easier editor "autoselection"=
 entry=2E  But if we wanted to =0D=0Athere could be more "where" convenienc=
e methods=2E =0D=0A=0D=0AOf course the criterion methods would be used to d=
o nested conditions=2E=0D=0AAnd if you wanted the =2Eand()=2Eor()=2EandNot(=
) readability, you could do=0D=0Athe logicals using the Criterion classes=
=2E=0D=0A=0D=0AThe same naming convention could be used for things like:=0D=
=0A=0D=0AaddJoin() =3D> join()=0D=0Aadd=2E=2E=2EOrderByColumn =3D> orderBy(=
column, direction)=0D=0AaddGroupBy =3D> groupBy()=0D=0A=0D=0Aand the like=
=2E=2E=0D=0A=0D=0AFinally, if we don't / can't do a factory to switch synta=
xes, then this=0D=0Anaming conventions would mean the old methods could sta=
y with a deprecated=0D=0Atag and the new methods would "stand out" as separ=
ate=2E=0D=0A=0D=0AJust some thoughts on this=2E=0D=0A=0D=0AGreg=0D=0A=0D=0A=
-----Original Message-----=0D=0AFrom: Thomas Vandahl [mailto:tv@apache=2Eor=
g] =0D=0ASent: Monday, December 12, 2011 10:59 AM=0D=0ATo: Apache Torque De=
velopers List=0D=0ASubject: Re: Change semantics of Criteria=2Eadd() and Cr=
iteria=2Eor()=0D=0A=0D=0AAm 12=2E12=2E2011 15:07, schrieb Thomas Fox:=0D=0A=
> 1) deprecate or remove the existing class and create a new one=2E Variant=
s:=0D=0A> 1a) move the new class to a new package=0D=0A=0D=0A+1=0D=0AWhile =
the danger of an automatic "Organize imports" still exists, it is =0D=0Apro=
bably the best solution=2E=0D=0A=0D=0A> 2) deprecate the existing methods a=
nd create new ones=2E We could=0D=0A> deprecate/remove the add methods and =
tell the user to use the and methods=2E=0D=0A> But I do not have a good new=
 name for the "or" methods=2E=0D=0A=0D=0AIts not really a good solution but=
 what about AND() and OR()=2E=0D=0A=0D=0A> 3) Because of TORQUE-168, new me=
thods have been added which use a Column=0D=0A> object as column name=2E Un=
til now, Strings have been used as column name=2E We=0D=0A> could deprecate=
/remove the methods which use String values=2E This means that=0D=0A> peopl=
e which do NOT use the constants from the Peer classes have more work=2E=0D=
=0A=0D=0A+2=0D=0AYeah, but I'd prefer more work over the possibility of wro=
ng code=2E Anytime=2E=0D=0A=0D=0ABye, Thomas=2E=0D=0A=0D=0A----------------=
-----------------------------------------------------=0D=0ATo unsubscribe, =
e-mail: torque-dev-unsubscribe@db=2Eapache=2Eorg=0D=0AFor additional comman=
ds, e-mail: torque-dev-help@db=2Eapache=2Eorg=0D=0A=0D=0ADukeCE Privacy Sta=
tement:=0D=0APlease be advised that this e-mail and any files transmitted w=
ith=0D=0Ait are confidential communication or may otherwise be privileged o=
r=0D=0Aconfidential and are intended solely for the individual or entity=0D=
=0Ato whom they are addressed=2E If you are not the intended recipient=0D=
=0Ayou may not rely on the contents of this email or any attachments,=0D=0A=
and we ask that you please not read, copy or retransmit this=0D=0Acommunica=
tion, but reply to the sender and destroy the email, its=0D=0Acontents, and=
 all copies thereof immediately=2E Any unauthorized=0D=0Adissemination, dis=
tribution or copying of this communication is=0D=0Astrictly prohibited=2E

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