IMHO This breaks backwards compatibility... -- Thadeus
On Sat, Jan 29, 2011 at 6:31 AM, Massimo Di Pierro < massimo.dipie...@gmail.com> wrote: > I treat this as a bug fix. > > On Jan 28, 12:52 pm, Anthony <abasta...@gmail.com> wrote: > > On Friday, January 28, 2011 12:58:30 PM UTC-5, Massimo Di Pierro wrote: > > > > > We need two steps: > > > > > 1) make it behave the same (which means case insensitive, ilike on > > > postgresql, now in trunk) > > > > Doesn't this change break backward compatibility, or are you treating > this > > as a bug fix? > > > > > 2) yes we can add a case_sensitive arg that defaults to True (not done > > > yet but I would take a patch). > > > > If we do want to maintain backward compatibility, wouldn't the new case > arg > > have to default to something like "let the RDBMS decide" -- it couldn't > just > > default to True (or False) because different databases have different > > defaults, no? On the other hand, if that's not a concern, do we want > > case_sensitive to default to True -- it sounds like not all databases > even > > offer that option? > > > > > > > > > > > > > > > > > > > > > On Jan 28, 11:37 am, Anthony <abas...@gmail.com> wrote: > > > > What if like() had something like a 'case' argument, with three > possible > > > > values: sensitive, insensitive, and rdbms_default (defaulting to > > > > rdbms_default)? > > > > > > We obviously need to maintain backward compatibility, but like() is a > > > web2py > > > > operator, not a specific RDBMS operator, so it would be nice if > there's > > > any > > > > easy way to make sure like() calls are as portable as possible > without > > > > requiring code changes. > > > > > > Anthony >
