I just stumbled over this change after I upgraded my application to 2.9.11
- so it seems like this will stay as it is? this is clearly breaking
backwards compatibility (with Postgres), something I did not expect at all.
Until now I had a query with
db.auth_user.first_name.startswith(searchterm)
I just found out that ilike doesn't work. from the code (2.9.11):
def ilike(self, value):
return self.like(case_sensitive=False)
the value is missing when calling self.like
Alex
On Thursday, November 27, 2014 12:59:05 PM UTC+1, Alex wrote:
I just stumbled over this change after I
That issue has been fixed in trunk.
see
https://github.com/web2py/web2py/commit/7e0e7eb6c861bb0a248dbd3ed0af121175a8d032
I suggest you to try trunk
Paolo
On Thursday, November 27, 2014 2:01:22 PM UTC+1, Alex wrote:
I just found out that ilike doesn't work. from the code (2.9.11):
def
ah, I see. I always use the case insensitive code page, which is probably
why I never had such an issue.
On Tuesday, September 23, 2014 2:13:15 PM UTC-7, Niphlod wrote:
sorry for being not that deeply explicit in the previous post.
contains() on list:something is case-insensitive.
If
I use 'Like' on mssql 2000 pretty much every day, what are you saying? why
can't it map to varchar?
On Monday, September 22, 2014 3:02:33 PM UTC-7, Niphlod wrote:
Unfortunately, mssql:// is there only for MSSQL 2000 (and others derived
from that baseclass).
It's a known
sorry for being not that deeply explicit in the previous post.
contains() on list:something is case-insensitive.
If you try to create a table with a TEXT field, then do a *LOWER(textfield)
LIKE '%whatever%'* on it.
You'll find out that while lots of functions can be applied to varchar, not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05-09-2014 17:03, Leonel Câmara wrote:
I feel like the only clean approach is to have a LIKE and a ILIKE.
Me too.
The problem is that we don't have any mechanism to make compatibility breaking
changes.
I think ideally applications should
Seems like a related issue still exists in web2py 2.9.11 for Microsoft SQL
Server.
list:integer type fields get mapped to 'text' type fields in MS SQL. The
text type fields cannot use functions like 'LOWER', only varchar type
fields can. So now queries like field.contains(integer) will not
The MSSQLAdapter could cast to varchar and avoid the problem.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are
Unfortunately, mssql:// is there only for MSSQL 2000 (and others derived
from that baseclass).
It's a known issue...unfortunately there's no operator / function that can
turn a 'text' into a something that gets a LIKE applied correctly without
the possibility of truncation, not until MSSQL
done
On Thursday, 11 September 2014 23:34:43 UTC-5, Joe Barnhart wrote:
Just set case_sensitive=False and it will work exactly the way you want
regardless of the convention chosen. I now set the case on my queries
since it seems prudent to do so. After all, I may change from Postgres to
Has this been finalized yet? The autocomplete widget also needs fixing.
--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because
Nothing is exactly broken, but autocomplete uses like in its queries when
it's not running on gae, so, once this is decided, we need to either set it
case_sensitive=False or make it use ilike (so it has the same behaviour on
gae and other adapters)
--
Resources:
- http://web2py.com
-
Just set case_sensitive=False and it will work exactly the way you want
regardless of the convention chosen. I now set the case on my queries
since it seems prudent to do so. After all, I may change from Postgres to
MySql or something and I don't want to be surprised.
-- Joe
On Thursday,
I do not like this. Should we put to a vote the default behavior of
db(...).like(...)? the thing is whatever we do will behave differently than
before on different databases.
On Wednesday, 3 September 2014 11:11:27 UTC-5, Anthony wrote:
On Wednesday, September 3, 2014 9:37:24 AM UTC-4,
On Friday, September 5, 2014 2:05:40 AM UTC-4, Massimo Di Pierro wrote:
I do not like this. Should we put to a vote the default behavior of
db(...).like(...)? the thing is whatever we do will behave differently than
before on different databases.
The problem is that there's no way to
I'm really unclear on this discussion.
I use postgres (pg) and sqlite a lot. When using web2py on both of them, I
was doing case-INsensitive like comparisons by default. Yet the
underlying DB systems have opposite native defaults -- pg defaults to
case-sensitive and sqlite defaults to
Should we put to a vote the default behavior of db(...).like(...)?
The change to LIKE was to mirror the standard SQL and make it
case-sensitive. Unfortunately, most web2py users expect LIKE to be
insensitive.
There really should have been two commands from the beginning, LIKE and
ILIKE
@Joe,
let me go back and look at my correspondence about this... we may revert
this change.
On Friday, 5 September 2014 05:34:11 UTC-5, Joe Barnhart wrote:
I'm really unclear on this discussion.
I use postgres (pg) and sqlite a lot. When using web2py on both of them,
I was doing
except that except postgresql any database can deal with case-sensitivity
or not at the database level, and doesn't have an ILIKE, so needs to go
through LOWER(), effectively doing a full scan by default ditching every
possible index.
Using by default a quirk that kills performances just
I think the big question here is - what's the old behaviour exactly?
This is important because backwards compatibility must be maintained at all
costs.
It doesn't seem to me as if the old behaviour was case insensitive, the old
behaviour was to do whatever the DB was configured to do. Am I
Well we are already using the quirk that kills performance. My point is
that irrespective as to the settings on an individual DB, we need two
methods for the framework: (1) case-insensitive and (2) case-sensitive.
The first uses ILIKE (pg) and CONTAINING (firebird) and whatever other DBs
I feel like the only clean approach is to have a LIKE and a ILIKE.
The problem is that we don't have any mechanism to make compatibility
breaking changes.
I think ideally applications should report what version of web2py or of the
DAL they were made for (and if they don't, we assume they're
Hi Anthony,
On 03/09/14 17:11, Anthony wrote:
I wonder if we should add an option to set that database-wide --
something like DAL(..., case_sensitive_like=False).
+1 from me!
Also, should .startswith and .endswith have a case sensitive option?
+1 again, but much less pressing, at least
But there is a disconnect between the devs and users who just need to
keep sites running without re-writing code because of an upgrade.
There's no disconnect, if this breaks backwards compatibility it's a bug
and it has to be fixed. I guess web2py needs more tests to prevent this
from
Hello Joe,
yes we made this change. The problem is that its previous behavior was
undetermined and was different across databases. So we treated it like a
bug.
LIKE is supposed to be case sensitive so we made sure like(...) is also
case sensitive consistently across supported databases (or so
On Wednesday, September 3, 2014 9:37:24 AM UTC-4, Massimo Di Pierro wrote:
Hello Joe,
yes we made this change. The problem is that its previous behavior was
undetermined and was different across databases. So we treated it like a
bug.
LIKE is supposed to be case sensitive so we made sure
27 matches
Mail list logo
