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 >> >
