On Fri, 2007-12-21 at 03:22 +0100, Patryk Zawadzki wrote:
[...]
> Malcolm, wouldn't it be reasonable to just call "SET SQL_AUTO_IS_NULL
> = 0" whenever a connection is established? It would prevent people
> from hitting this bug even when using custom queries (like
> QuerySet.extra) and would eli
2007/12/21, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> Okay, everybody (or, at least, some people) are putting way to much
> thought into this. Stop now.
>
> I've already worked around it in queryset-refactor so that we never
> generate this type of query. It was used in a test and as a way to avoi
On Thu, 2007-12-20 at 13:12 -0800, AmanKow wrote:
> Ok, I'm stymied... it's a session variable only, not global and
> therefore I cannot change the default value in the options file.
> Also, it is not dynamic, which means that it requires a server restart
> to be effective, but then it uses the d
AmanKow said the following:
> Well, the value of this can be accessed via:
> SELECT @@session.sql_auto_is_null;
> which gets you the result of 1
> If you then perform a
> SET SESSION sql_auto_is_null=0;
> and perform the above query again, the value is. 1
> As I mentioned earlier, it isn't dyn
Well, the value of this can be accessed via:
SELECT @@session.sql_auto_is_null;
which gets you the result of 1
If you then perform a
SET SESSION sql_auto_is_null=0;
and perform the above query again, the value is. 1
As I mentioned earlier, it isn't dynamic anyway, so even if it changed
to 0 th
AmanKow said the following:
> Any mysql gurus out there with some advice as to how to turn off this
> behavior?
The mysql docs and several things I've found online (including code from
Rails) indicates that simply "SET SQL_AUTO_IS_NULL=0" should work,
unless they broke it :)
--
Collin Grady
Th
Ok, I'm stymied... it's a session variable only, not global and
therefore I cannot change the default value in the options file.
Also, it is not dynamic, which means that it requires a server restart
to be effective, but then it uses the default behavior, oh, my head
hurts.
Ok, I take it back...
Yikes!... it's a session variable only... makes it hard to change the
default behavior...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develope
I don't think mysql adding a setting to turn off/on behavior that
allows integration with some odbc applications as evidence of
hallucinogen use . It is an unfortunate choice to have the
non-standard behavior as the default, however.
Other than the above test, I find it hard to imagine someone f
On Wed, 2007-12-19 at 10:18 -0500, Karen Tracey wrote:
[...]
>
> Looks like it is an oddball (high quality weed?) mysql setting (see
> http://dev.mysql.com/doc/refman/5.1/en/set-option.html):
>
> * SQL_AUTO_IS_NULL = {0 | 1}
>
> If set to 1 (the default), you can find th
On Dec 19, 2007 8:51 AM, Malcolm Tredinnick <[EMAIL PROTECTED]>
wrote:
>
>
> On Wed, 2007-12-19 at 14:36 +0100, Patryk Zawadzki wrote:
> > 2007/12/19, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> > > Clearly something is amiss here, since the "id" attribute is a primary
> > > key column (not NULL and
On Wed, 2007-12-19 at 14:36 +0100, Patryk Zawadzki wrote:
> 2007/12/19, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> > Clearly something is amiss here, since the "id" attribute is a primary
> > key column (not NULL and unique, by definition), so nothing should match
> > against the query. The genera
2007/12/19, Malcolm Tredinnick <[EMAIL PROTECTED]>:
> Clearly something is amiss here, since the "id" attribute is a primary
> key column (not NULL and unique, by definition), so nothing should match
> against the query. The generated SQL can be seen by looking at
> Choices.objects.filter(id__exac
If anybody would like to look at a strange MySQL problem, I'd appreciate
some insights.
Checkout the queryset-refactor branch and run the null_queries test with
the 'mysql' (or 'mysql_old') backend.
`--> ./runtests.py --settings=settings1 null_queries
---
14 matches
Mail list logo
