You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cayenne.apache.org by Andrus Adamchik <an...@objectstyle.org> on 2014/11/21 13:19:21 UTC
Variations of 'like'
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
Re: Variations of 'like'
Posted by Mike Kienenberger <mk...@gmail.com>.
Yeah, I was about to comment along those lines as well.
For chained operations, readability of the code needs to be a primary focus.
On Fri, Nov 21, 2014 at 9:56 AM, Michael Gentry <mg...@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 <an...@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 <mg...@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 <an...@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
>>>
>>
Re: Variations of 'like'
Posted by Aristedes Maniatis <ar...@maniatis.org>.
On 24/11/2014 5:26pm, Andrus Adamchik wrote:
>> 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).
Yes, good point. Perhaps we need a big warning in the javadocs like this:
...likeIgnoreCase()
Note: Case insensitive matching is implemented in Cayenne by performing UPPER() on both sides of the query. Where you haven't added a functional index for this purpose (and some databases do not support functional indices at all), this can result in a huge performance hit. Use this method with caution and consider instead switching your database column to a case insensitive collation for better performance.
...like()
Although this method appears to be juxtaposed with likeIgnoreCase(), if your column collation is case-insensitive, this method will always perform a case insensitive search.
Ari
--
-------------------------->
Aristedes Maniatis
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Variations of 'like'
Posted by Andrus Adamchik <an...@objectstyle.org>.
>
> 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 <ar...@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 <mg...@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 <an...@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 <mk...@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
>>>>> <an...@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 <mg...@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 <mg...@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
>
Re: Variations of 'like'
Posted by Aristedes Maniatis <ar...@maniatis.org>.
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 <mg...@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 <an...@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 <mk...@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
>>>> <an...@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 <mg...@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 <mg...@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
Re: Variations of 'like'
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mg...@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 <an...@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 <mk...@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
>>> <an...@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 <mg...@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 <mg...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>>
Re: Variations of 'like'
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@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 <mk...@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
> > <an...@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 <mg...@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 <mg...@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
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
Re: Variations of 'like'
Posted by Michael Gentry <mg...@masslight.net>.
Yeah, but an ORM shields me from that. :-)
On Sat, Nov 22, 2014 at 7:02 AM, Andrus Adamchik <an...@objectstyle.org>
wrote:
> FWIW PostgreSQL uses "ILIKE" for that purpose.
>
> > On Nov 22, 2014, at 2:43 PM, Andrus Adamchik <an...@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 <mk...@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
> >> <an...@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 <mg...@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 <mg...@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
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
> >
>
>
Re: Variations of 'like'
Posted by Andrus Adamchik <an...@objectstyle.org>.
FWIW PostgreSQL uses "ILIKE" for that purpose.
> On Nov 22, 2014, at 2:43 PM, Andrus Adamchik <an...@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 <mk...@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
>> <an...@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 <mg...@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 <an...@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 <mg...@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 <an...@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
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: Variations of 'like'
Posted by Andrus Adamchik <an...@objectstyle.org>.
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 <mk...@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
> <an...@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 <mg...@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 <an...@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 <mg...@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 <an...@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
>>>>>
>>>>
>>>
>>
>
Re: Variations of 'like'
Posted by Mike Kienenberger <mk...@gmail.com>.
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
<an...@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 <mg...@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 <an...@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 <mg...@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 <an...@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
>>>>
>>>
>>
>
Re: Variations of 'like'
Posted by Andrus Adamchik <an...@objectstyle.org>.
enum also makes it needlessly verbose :-/
But yeah, I take your point.
> On Nov 21, 2014, at 5:56 PM, Michael Gentry <mg...@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 <an...@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 <mg...@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 <an...@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
>>>
>>
>
Re: Variations of 'like'
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@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 <mg...@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 <an...@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
>>
>
Re: Variations of 'like'
Posted by Andrus Adamchik <an...@objectstyle.org>.
> 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 <mg...@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 <an...@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
>
Re: Variations of 'like'
Posted by Michael Gentry <mg...@masslight.net>.
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 <an...@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