![]() On all DBs except MySQL this was a no-op, but MySQL returned (for string-type data) either the utf8 binary or case-insensitive collation as appropriate for the given lookup type. One way I experimented with doing it was adding a new call into the database backend to get an appropriate collation string for a given lookup type and column datatype. That's not particularly hard to do either, in terms of lines of code. Rather I'd prefer to make the existing lookups work properly regardless of database collation. I think new lookup types and settings would just add to the confusion. If we were to fix MySQL exact/iexact lookup, this would not be the approach I would take. You've left out of your estimate the lines of doc required to explain the new lookup types and settings you propose, and the estimated person-hours per year needed to answer questions related to them on their mailing list and IRC, and to deal with the resulting tickets when someone sets things up incorrectly, or wants to use different collations for different tables/columns, etc. (People on KDE bugzilla have told me I should never tell them whether I think something is easy to implement, but nevertheless it’s a couple of lines for both changes. For case-sensitive people: an option to set a collation for case-insensitive matches, for example in the settings module.īoth options preserve backwards compatibility and both should be easy to implement.Maybe the ‘s’ prefix for ‘sensitive’, or ‘b’ for binary: bcontains, bexact, bregex and so on. For those who have case-insensitive collation in MySQL: a lookup option that would always invoke case-sensitive matching.Maybe in addition to contains and icontains something like scontains is also needed? I’ve read what Django documentation has to say about collation, and while you might be justified in having ‘exact’ return what the database considers exact (for example, for purposes of UNIQUE indices), it’s wrong not to provide a lookup option that would consistently test for case-sensitive equality across DBMSs. It would solve a practical problem: I want iexact to differ from exact and icontains to differ from contains (please note these completely reasonable requirements conflict on current MySQL under current Django implementation regardless of collation settings). Maybe the most reasonable solution would be a setting like FORCE_COLLATION_FOR_CI (maybe MySQL-specific, maybe it can be usable for other DBMSs), that would determine how to collate values for which no collation is specified? However, for something_icontains the database does have to determine some collation, and if the default collation is case insensitive, some fallback has to be derived. You’re right Unicode is quite hard to implement properly. (It does perform LOWER('COMMITTED' COLLATE utf8_turkish_ci) correctly, however.) What about altering the above table, making it 'COLLATE utf8_general_ci LIKE %s' for cases where the default collation isn’t case-insensitive? It thinks that 'ı' is LIKE 'i' and 'groß' is not LIKE 'GROSS'. However, MySQL doesn’t seem to implement the Unicode collation trickery correctly. ![]() That sounds strange, because case-sensitive matching is no harder than a simple memcpy, it’s case-insensitive matching that is problematic. The aforementioned thread says that ‘case-sensitive matching with the default utf_*_ci collations’ and overall making ‘things like that work regardless of collation’ is ‘really, really hard’. So, case-sensitivity is explicitly requested, while case-insensitivity is implied. In fact, here’s how Django defines operators for the MySQL backend: This is not field_icontains but rather some field_ usingdefaultsettingscontains. So, the programmer has told Django explicitly, ‘I want case-insensitive comparison’, and Django tells MySQL, ‘We want default comparison’. For icontains and MySQL, Django generates ‘x LIKE '%y%'’. Secondly, I disagree with the ‘You set the database collation and Django respects that’ approach shown there. ![]() Firstly, this is a known problem, see /group/django-users/browse_thread/thread/2936ad3387c4b369.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |