I agree with Thadeus here that "like" should be what it means in each
case. Changing the default meaning of "like" in each RDBMS will cause
confusion. "ilike" can be a web2py thing, but "like" should be
specific to each RDMS.
On Jan 28, 9:46 am, Thadeus Burgess <thade...@thadeusb.com> wrote:
> I disagree! Your playing with things that shouldn't be played with.
>
> Not to mention that now you have just broken some of my apps that perform
> case-sensitive queries in postgres.... this is just plain wrong in so many
> ways.
>
> Add a new identifier to DAL... give me
>
> db(db.table.name.like('%printer%'))
>
> and then for case insensitive
>
> db(db.table.name.ilike('%printer%')).
>
> like would perform the actual operation that would happen from the RDBMS,
> and ilike can be a web2py playing god version that makes sure all rdbmses
> act the same.
>
> Case sensitive search is one of the benefits of using postgres instead of
> mysql!
>
> --
> Thadeus
>
> On Fri, Jan 28, 2011 at 8:40 AM, Massimo Di Pierro <
>
> massimo.dipie...@gmail.com> wrote:
> > I agree the behavior should be uniform. The easiest way is to make the
> > LIKE always case insensitive. I am patching trunk to use ILIKE with
> > postgresql.
>
> > On Jan 28, 3:01 am, KMax <mkostri...@gmail.com> wrote:
> > > On 7 дек 2010, 00:31, Fran <francisb...@gmail.com> wrote:
>
> > > > - minimally it should be in a FAQ (ideally in the next Book) & ideally
> > > > we could have a case_sensitive=True option for the DAL like()
> > > > operator...to ensure that both pgsql & mysql/sqlite existing apps
> > > > didn't break, it could default differently depending on the db type?
>
> > > +1 vote
> > > sqlite has some issue with not ascii chars compare, but work in
> > > progress
> > > pgsql has ilike which works like mysql like (fix me)
>
> > > I' just patch dal to use ilike in .like() query for postgres, but it
> > > more cheat then solution.
>
>
