cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrus Adamchik <and...@objectstyle.org>
Subject Re: Variations of 'like'
Date Mon, 24 Nov 2014 06:26:48 GMT
> 
> What exactly will likeIgnoreCase do? If it is just wrapping UPPER() around both sides,
I've found this to be a huge performance hit unless you are able to create functional indexes
(which you can only do on some dbs). Perhaps we don't want to make it too easy for people
to do that without thinking about it.

likeIgnoreCase is existing API. So the same same thing it always did I guess (UPPER). TIL
that PostgreSQL has "ILIKE" operator:

http://www.postgresql.org/docs/9.0/static/functions-matching.html

Not sure if that makes things better compared to UPPER for PG users (??)

> Will there be any awareness inside Cayenne of whether the column is already in a case-insensitive
collation? Is that even possible in JDBC4?

We've discussed it before and didn't have a solution (other than a global policy for the entire
app). Perhaps we can implement some "adaptive" algorithm that gradually accumulates collation
metadata over time for the queries run by the app. Haven't given it much thought yet. Perhaps
we can start a separate thread if we want to discuss the backend (vs. the user API).

Andrus 


> On Nov 24, 2014, at 2:06 AM, Aristedes Maniatis <ari@maniatis.org> wrote:
> 
> What exactly will likeIgnoreCase do? If it is just wrapping UPPER() around both sides,
I've found this to be a huge performance hit unless you are able to create functional indexes
(which you can only do on some dbs). Perhaps we don't want to make it too easy for people
to do that without thinking about it.
> 
> Will there be any awareness inside Cayenne of whether the column is already in a case-insensitive
collation? Is that even possible in JDBC4?
> 
> Ari
> 
> 
> On 23/11/2014 3:15am, Andrus Adamchik wrote:
>> While I don't want us to devolve into Perl, still there's something to be said for
having easy-to-understand API conventions that cut down the boilerplate. I think this also
improves overall readability. 
>> 
>> Not sure if "likeI" is too much though. I am fine with keeping 'likeIgnoreCase'.
>> 
>> Andrus
>> 
>> 
>>> On Nov 22, 2014, at 5:40 PM, Michael Gentry <mgentry@masslight.net> wrote:
>>> 
>>> I still prefer things to be spelled out.  My personal philosophy is you are
>>> writing code to be read, not writing code to be written.  To me, it helps
>>> when maintaining code or picking up someone else's code down the line.
>>> 
>>> mrg
>>> 
>>> 
>>> On Sat, Nov 22, 2014 at 6:43 AM, Andrus Adamchik <andrus@objectstyle.org>
>>> wrote:
>>> 
>>>> so, case sensitivity naming has its own inconsistencies already:
>>>> 
>>>> ExpressionFactory.likeIgnoreCase(..)
>>>> Property.likeInsensitive(..) // this is 4.0 API, we can change it
>>>> 
>>>> I wonder if we should use the third shorter form going forward:
>>>> 
>>>> likeI(..) # "I" is alluding to regex "i" flag.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Andrus
>>>> 
>>>> 
>>>> 
>>>>> On Nov 21, 2014, at 6:08 PM, Mike Kienenberger <mkienenb@gmail.com>
>>>> wrote:
>>>>> 
>>>>> Not only readability, but also picking the right options.
>>>>> 
>>>>> For me, code completion on a method name is the quickest way to work
>>>>> through chained query options.   An enum argument is also workable,
>>>>> but extra typing.   But a generic type like int or boolean makes it
>>>>> difficult to figure out what to specify without looking up the
>>>>> documentation.
>>>>> 
>>>>> On Fri, Nov 21, 2014 at 10:02 AM, Andrus Adamchik
>>>>> <andrus@objectstyle.org> wrote:
>>>>>> enum also makes it needlessly verbose :-/
>>>>>> 
>>>>>> But yeah, I take your point.
>>>>>> 
>>>>>> 
>>>>>>> On Nov 21, 2014, at 5:56 PM, Michael Gentry <mgentry@masslight.net>
>>>> wrote:
>>>>>>> 
>>>>>>> I'd avoid true/false for that purpose.  We had the same thing
in
>>>>>>> orderings before I changed it to an enum.  I'd specify it in
the
>>>>>>> method name or use an enum that makes sense when reading it.
>>>>>>> 
>>>>>>> mrg
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Nov 21, 2014 at 9:47 AM, Andrus Adamchik <
>>>> andrus@objectstyle.org> wrote:
>>>>>>>>> So are you thinking something like:
>>>>>>>>> Artist.ARTIST_NAME.contains("Van")?
>>>>>>>> 
>>>>>>>> yep.
>>>>>>>> 
>>>>>>>>> Also, what about
>>>>>>>>> case-insensitive?
>>>>>>>> 
>>>>>>>> Probably as a second true/false argument? I started to dislike
the
>>>> look of "likeIgnoreCase" recently :)
>>>>>>>> 
>>>>>>>> Property.contains(string);
>>>>>>>> Property.contains(string, true);
>>>>>>>> Property.contains(string, false);
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Andrus
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Nov 21, 2014, at 5:33 PM, Michael Gentry <mgentry@masslight.net>
>>>> wrote:
>>>>>>>>> 
>>>>>>>>> I 'like' this.
>>>>>>>>> 
>>>>>>>>> So are you thinking something like:
>>>>>>>>> Artist.ARTIST_NAME.contains("Van")?  Also, what about
>>>>>>>>> case-insensitive?
>>>>>>>>> 
>>>>>>>>> mrg
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Fri, Nov 21, 2014 at 7:19 AM, Andrus Adamchik <
>>>> andrus@objectstyle.org> wrote:
>>>>>>>>>> Another API idea that I just had while analyzing
boilerplate code
>>>> of the client Cayenne apps. An argument to Property.like(..) (or second
>>>> argument to ExpressionFactory.likeExp(..)) requires a full pattern to match
>>>> against. So people would often write their own utility code to wrap a
>>>> String in "%" signs. Cayenne can easily take care of this via the following
>>>> methods:
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Property.contains(string);
>>>>>>>>>> // same as Property.like("%" + string + "%");
>>>>>>>>>> 
>>>>>>>>>> Property.startsWith(string);
>>>>>>>>>> // same as Property.like(string + "%");
>>>>>>>>>> 
>>>>>>>>>> Property.endsWith(string);
>>>>>>>>>> // same as Property.like("%" + string);
>>>>>>>>>> 
>>>>>>>>>> In addition to saving the user from String concatenation,
these new
>>>> methods can do proper symbol escaping, making "like" much safer to use.
>>>>>>>>>> 
>>>>>>>>>> Andrus
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>> 
> 
> -- 
> -------------------------->
> Aristedes Maniatis
> GPG fingerprint CBFB 84B4 738D 4E87 5E5C  5EFA EF6A 7D2E 3E49 102A
> 


Mime
View raw message