> Having read in other posts about MySQL being case insensitive by
> default, I have tried using the __exact method to force exact
> matching, however, this still finds the alternative case version in
> the table. Note there are no duplicates in the table on this field.
>
> Example:
> x=Datatable.objects.get(code__exact='AbCd')
> y=x.code
> print y
> 'AbcD'
>
> Can anyone advise on how I might overcome this issue. For our model,
> it is vital that we can identify distinct case sensitive entries.
Well, GIYF:
mysql case-sensitive
returns the top hit where it's advised that if this matters, you
can alter your column definition to include "COLLATE latin1_bin"
create table case_bin_test (
word VARCHAR(10))
CHARACTER SET latin1
COLLATE latin1_bin;
You should be able to do this after you create your DB. I don't
know off the top of my head if that is only available table-wide,
or if you can limit it to a given field like
create table case_bin_test (
word VARCHAR(10)
CHARACTER SET latin1
COLLATE latin1_bin,
non_binary_field VARCHAR(10)
);
If you roll your own SQL, MySQL also supports using
SELECT * FROM tblFoo WHERE fieldname LIKE BINARY 'AbCd'
using "LIKE BINARY" rather than '='
Another option would be to do a CAST(fieldname AS BINARY) to
force your field to be compared as a binary rather than as strings.
http://mysqldatabaseadministration.blogspot.com/2006/09/case-sensitive-mysql.html
http://dev.mysql.com/doc/refman/5.0/en/cast-functions.html
http://www.delphifaq.com/faq/databases/mysql/f801.shtml
Integrating this into the Django ORM would take a bit more work,
though it should be possible to cram that into the MySQL code.
Given the meaning of __exact and __iexact, it would make sense to
force __exact to have the behavior you describe. However, sloppy
coding might break for some folks who unthinkingly used __exact
when they really meant __iexact.
It might even be as simple as tweaking the
db/backends/mysql/base.py and changing the entry in the
OPERATOR_MAPPING value from
'exact': '= %s',
to
'exact': 'LIKE BINARY %s',
(though searches with metachars like "%" and "_" might need to be
escaped somehow before doing this)
If you monkey with the ORM, you'd want to ensure that you run the
test-suite to smoke out any peculiarities.
-tim
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
