> > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 >>>>> <[email protected]> wrote: >>>>>> enum also makes it needlessly verbose :-/ >>>>>> >>>>>> But yeah, I take your point. >>>>>> >>>>>> >>>>>>> On Nov 21, 2014, at 5:56 PM, Michael Gentry <[email protected]> >>>> 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 < >>>> [email protected]> 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 <[email protected]> >>>> 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 < >>>> [email protected]> 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 >
