Alex Gaynor wrote:
>
>
> On Tue, Mar 24, 2009 at 2:51 PM, Michael Glassford wrote:
>
>
> Alex Gaynor wrote:
> >
> >
> > On Tue, Mar 24, 2009 at 2:39 PM, Michael Glassford wrote:
>
> [snip model definition, etc.]
>
> > When I run the tests under Django 0.96.3, I get the expected
> exception:
> > "DoesNotExist: ModelA matching query does not exist."
> >
> > However, under Django 1.0, 1.0.1, 1.0.2, and the current
> trunk (revision
> > 10162 at the time when I tested this), the
> "ModelA.objects.get(pk=None)"
> > statement unexpectedly returns the object created by the
> > "ModelA.objects.create()" on the previous line.
> >
> >
> > Mike
> >
> >
> >
> >
> > Under MySQL doing a query of the form WHERE primary_key IS NULL
> returns
> > the last created row.
> >
> > Alex
>
>
>
> Not here:
>
> mysql> show create table myapp_modela;
>
> +--------------+----------------------------------------------------------------------------------------------------------------------------------+
> | Table | Create Table
>
> |
>
> +--------------+----------------------------------------------------------------------------------------------------------------------------------+
> | myapp_modela | CREATE TABLE `myapp_modela` (
> `id` int(11) NOT NULL auto_increment,
> PRIMARY KEY (`id`)
> ) ENGINE=InnoDB DEFAULT CHARSET=utf8 |
>
> +--------------+----------------------------------------------------------------------------------------------------------------------------------+
> 1 row in set (0.00 sec)
>
> mysql> insert into myapp_modela values (1);
> Query OK, 1 row affected (0.00 sec)
>
> mysql> select * from myapp_modela where id is NULL;
> Empty set (0.00 sec)
>
>
>
> Also, that doesn't explain why Django 0.96 does what I expected.
>
>
>
> I'm almost positive the MySQL CLI operates differently for the purposes
> of this query. The reason the queries do different things in .96 is
> that in .96 that query becomes id = NULL rather than id IS NULL, which
> MySQL handles differently.
After more research, it turns out that my example doesn't display the
problem because it isn't testing for the right thing. The actual
behavior that MySQL implements is to return the last row inserted using
an auto-increment id (which the above did not, since I supplied the id).
Changing the example accordingly:
mysql> insert into myapp_modela values();
Query OK, 1 row affected (0.00 sec)
mysql> select * from myapp_modela where id is null;
+----+
| id |
+----+
| 6 |
+----+
1 row in set (0.00 sec)
However, this behavior can be turned off:
mysql> set sql_auto_is_null = 0; #Turn off using session variable
Query OK, 0 rows affected (0.00 sec)
mysql> insert into myapp_modela values();
Query OK, 1 row affected (0.00 sec)
mysql> select * from myapp_modela where id is null;
Empty set (0.00 sec)
Django can be patched to do this automatically. There may be a better
way to do it, but I've figured out that in db/backends/mysql/base.py,
inside the DatabaseWrapper._cursor function, adding the line
"cursor.execute('SET sql_auto_is_null=0;')" immediately after the
"cursor = CursorWrapper(self.connection.cursor())" line will do it.
Should I submit a patch or is this just something that's not going to be
fixed?
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
-~----------~----~----~----~------~----~------~--~---
