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>
Date: Thu, 19 Oct 2006 13:24:54 -0700 (PDT)
From: Thomas Fischer <tfischer@apache.org>
To: torque-dev@db.apache.org
Subject: Re: Doubt in the SQLExpression formed by buildLike method
In-Reply-To: <6f13c2a30610120211m17257299x4a300683de517d32@mail.gmail.com>
Message-ID: <20061019130726.W12478@minotaur.apache.org>
References: <6f13c2a30610120211m17257299x4a300683de517d32@mail.gmail.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="0-551856507-1161289494=:12478"

--0-551856507-1161289494=:12478
Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE

Hm, at least the result of the method does not match the javadoc comment.=
=20
I would think that the code is faulty.

But even if the code was correct, the logic of removing the escape=20
character and replacing a LIKE with an =3D if a % sign is escaped is dubiou=
s=20
at least. What should happen for LIKE "%test\%" ???

My personal feeling is that the LIKE should not be changed in any case (if=
=20
the user wants a like comparison, he gets it, otherwise he should not have=
=20
used LIKE) and that the \ should be replaced with the db-specific escape=20
character.

Correctly escaping the wildcards would probably mean that we would have to
add a method in the DB adapter which does the escaping. We should check
whether this is possible for all DB's (i.e. are the escape characters the
same e.g. for string constants in the like clause and ordinary strings ?)

But then again, should this behaviour changed in a bugfix release ?=20
In my opinion, correctly escaping the wildcard would be a good thing to=20
do, but we should keep the LIKE -> =3D replacement till the next major=20
release.

Any other opinions ?

    Thomas

On Thu, 12 Oct 2006, Parthasarathy T wrote:

> Hi all,
>
> I have a small doubt in the SQLExpression formed by the buildLike method.=
 If
> i understand the comments correctly if criteria =3D 50\%, it will be chan=
ged
> to columnName =3D 50%
>
> /**
>    * Takes a columnName and criteria and builds an SQL phrase based
>    * on whether wildcards are present and the state of the
>    * ignoreCase flag.  Multicharacter wildcards % and * may be used
>    * as well as single character wildcards, _ and ?.  These
>    * characters can be escaped with \.
>    *
>    * e.g. criteria =3D "fre%" -> columnName LIKE 'fre%'
>    *                        -> UPPER(columnName) LIKE UPPER('fre%')
>    *      criteria =3D "50\%" -> columnName =3D '50%'
>    *
>    * @param columnName A column name.
>    * @param criteria The value to compare the column against.
>    * @param comparison Whether to do a LIKE or a NOT LIKE
>    * @param ignoreCase If true and columns represent Strings, the
>    * appropriate function defined for the database will be used to
>    * ignore differences in case.
>    * @param db Represents the database in use, for vendor specific
> functions.
>    * @param whereClause A StringBuffer to which the sql expression
>    * will be appended.
>    */
>   static void buildLike(String columnName,
>                          String criteria,
>                          SqlEnum comparison,
>                          boolean ignoreCase,
>                          DB db,
>                          StringBuffer whereClause)
>   {
>
> Check the loop logic below - first sb is filled with *5 *and then *0 *and
> then it encounters \ - the code now enters the *case BACKSLASH: *where we
> check the next character while is % so it enters the % case and so the
> position gets incremented by 1 automatically - the checkWildcard at this
> time will be still \ and not % and so when the checkWildcard gets appende=
d
> to sb we will be appending \ and we would have skipped % altogether (beca=
use
> of position++)
> At the end of the loop we will be having sb=3D 50\ and not 50%. Is this a
> bug??
>
> Most of time we may not have faced the problem because we would have come=
 in
> criteria =3D 50\\% (because of *quoteAndEscapeText() *method appending an
> extra slash for most dbs).
>
> StringBuffer sb =3D *new* StringBuffer();
>
> *  StringBuffer sb =3D new StringBuffer();
>       while (position < criteria.length())
>       {
>           char checkWildcard =3D criteria.charAt(position);*
>
> *            switch (checkWildcard)
>           {
>           case BACKSLASH:
>               // Determine whether to skip over next character.
>               switch (criteria.charAt(position + 1))
>               {
>               case '%':
>               case '_':
>               case '*':
>               case '?':
>               case BACKSLASH:
>                   position++;
>                   break;
>               }
>               break;
>           case '%':
>           case '_':
>               escapeCharFound =3D true;
>               equalsOrLike =3D comparison.toString();
>               break;
>           case '*':
>               equalsOrLike =3D comparison.toString();
>               checkWildcard =3D '%';
>               break;
>           case '?':
>               equalsOrLike =3D comparison.toString();
>               checkWildcard =3D '_';
>               break;
>           }*
>
> *            sb.append(checkWildcard);
>           position++;
>       }
>       whereClause.append(equalsOrLike);*
>
> sb.append(checkWildcard);
>
> position++;
>
> }
>
> Thanks,
>
> *T.Parthasarathy *=95  SunGard  =95 Offshore Services =95 Divyasree Chamb=
ers
> Langford Road =95 Bangalore 560025 India
> Tel +91-80-2222-0501 =95 Mobile +91-99450-00394 =95 Fax +91-80-2222-0511 =
=95 *
> www.sungard.com*
>
> *Please note my email address =96
> Parthasarathy.Thandavarayan@sos.sungard.com.  Please update your
> contact list and use this address for all
> future communication.*
>
> CONFIDENTIALITY: This email (including any attachments) may contain
> confidential, proprietary and privileged information, and unauthorized
> disclosure or use is prohibited. If you received this email in error, ple=
ase
> notify the sender and delete this email from your system. Thank you.
>

--0-551856507-1161289494=:12478
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: torque-dev-unsubscribe@db.apache.org
For additional commands, e-mail: torque-dev-help@db.apache.org
--0-551856507-1161289494=:12478--