cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Gentry <mgen...@masslight.net>
Subject Re: Variations of 'like'
Date Sat, 22 Nov 2014 14:41:12 GMT
Yeah, but an ORM shields me from that.  :-)


On Sat, Nov 22, 2014 at 7:02 AM, Andrus Adamchik <andrus@objectstyle.org>
wrote:

> FWIW PostgreSQL uses "ILIKE" for that purpose.
>
> > On Nov 22, 2014, at 2:43 PM, 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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message