Malcolm Tredinnick wrote:
> On Tue, 2009-03-24 at 20:40 -0400, Karen Tracey wrote:
> [...]
>> But the decision was made to not add this overhead to the start of
>> every connection. If you read the last paragraph you'll note it wasn't
>> an emphatic "no, never shall we do this" type of decision but I don't
>> know that anything has come to light to change the decision here,
>> other than a couple of people have noticed the oddness.
>
> I think it's pretty emphatic these days. I wasn't rushing to judgement
> at the time, but nothing has happened in the interim to convince me that
> sort of change would be a good idea. We consistently reflect the
> database server's behaviour throughout Django. This is another case of
> that. If people choose MySQL, they get to experience all the
> consequences of that choice, both good and bad.
>
> I'd be strongly against changing it now. Adding extra overhead to every
> single connection to work around something that 99.9% of normal code
> won't do anyway and can easily be avoided would be irresponsible. If
> somebody wants to pass in pk=None and doesn't want the MySQL behaviour
> to occur they can use a server that doesn't do that or configure it off
> (and remember to do that every single time they use a different MySQL
> install). In practice, though, simply not sending through pk=None is the
> easy solution (that's how Django works internally for example).
>
> Regards,
> Malcolm
For those researching this in the future: the best fix I ultimately came
up with is to add "DATABASE_OPTIONS = {'init_command': 'set
sql_auto_is_null=0'}" to settings.py. Perhaps this could be added to the
documentation somewhere.
At the risk of being annoying, let me suggest one more Django patch (see
the bottom of this message). I only suggest it because it seems to
overcome two of the biggest objections to the previous patch: a) it
doesn't require the extra overhead that the other patch did every time a
new connection is made, and b) if the user really wants MySQL's odd
default behavior, they can get it back by putting "DATABASE_OPTIONS =
{'init_command': 'set sql_auto_is_null=1'}" in their settings.py.
If you're still not interested, you can just tell me to fix it in my
settings.py file and I can do that. But everyone seems to agree that
it's a silly default behavior, and it has surprised more than just me.
To me, it seems more logical for the few (if any) people who actually
want this MySQL behavior when using Django to change their settings.py
instead of the many who don't want it having to do so (though,
admittedly, it seems that not many people have actually run into this
problem and both realized what was going on and reported it).
Here's the patch. It's a concept patch only; the actual implementation
may need to be improved somewhat in the case that kwargs already has an
init_command entry:
Index: django/db/backends/mysql/base.py
===================================================================
--- django/db/backends/mysql/base.py (revision 19489)
+++ django/db/backends/mysql/base.py (working copy)
@@ -273,6 +273,9 @@
if settings.DATABASE_PORT:
kwargs['port'] = int(settings.DATABASE_PORT)
kwargs.update(self.options)
+ init_command = kwargs.setdefault('init_command', 'SET
sql_auto_is_null = 0')
+ if 'sql_auto_is_null' not in init_command:
+ kwargs['init_command'] = init_command + ',
sql_auto_is_null = 0'
self.connection = Database.connect(**kwargs)
self.connection.encoders[SafeUnicode] =
self.connection.encoders[unicode]
self.connection.encoders[SafeString] =
self.connection.encoders[str]
Mike
--~--~---------~--~----~------------~-------~--~----~
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
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
