Karen Tracey <kmtracey <at> gmail.com> writes:
>
>
> On Mon, Jan 5, 2009 at 3:37 PM, JonUK <jdoull <at> flinttechnology.co.uk>
wrote:
>
>
>
> Apologies as this is a repost, but I'm completely stuck!
> I'm using django 1.0.2 and the tagging app to retrieve a tag via a
> database "in" query, and something is causing the query results to be
> discarded.
> In particular, this line of code from tagging.utils.get_tag_list()
> executes:
> return Tag.objects.filter(name__in=[force_unicode(tag)
> for tag in tags])
> and at this point:
> (Pdb) p tags
> [u'sea']
> The thread of execution can be traced into the method
> django.db.models.sql.query.execute_sql(self, result_type=MULTI), and
> to this line of code:
> cursor.execute(sql, params)
> and over here:
> >
> c:\python26\lib\site-packages\django\db\models\sql\query.py(1735)
> execute_sql()
> -> cursor.execute(sql, params)
> (Pdb) p sql
> 'SELECT "tagging_tag"."id", "tagging_tag"."name" FROM "tagging_tag"
> WHERE "tagging_tag"."name" IN (%s) ORDER BY "tagging_tag"."name" ASC'
> (Pdb) p params
> (u'sea',)
> (Pdb)
> If I audit what's submitted to MySQL via MySQL logging, it reports:
> SELECT `tagging_tag`.`id`, `tagging_tag`.`name` FROM `tagging_tag`
> WHERE `tagging_tag`.`name` IN ('sea') ORDER BY `tagging_tag`.`name`
> ASC
> which looks correct - however django returns an empty list.
> If I execute the query interactively in MySQL, I get the expected
> (correct) result:
> +----+------+
> | id | name |
> +----+------+
> | 28 | Sea |
> +----+------+
> 1 row in set (0.00 sec)
> I suspect this is a configuration problem but have no idea where to
> look - can anyone help?
>
>
> I can't recreate with a similar (though without tagging, just doing a similar
in query for one of my models) query on my MySQL DB/django app. The
.filter(xxxx__in=[...]) returns case-insensitive results as expected. As
you've
traced it down to where the SQL executes, have you gone farther to determine if
somehow that SQL query when issued by Django isn't returning any results while
the one you issue in the mysql command does? It'd be pretty bizarre, but maybe
the SQL is returning the same result but somehow it's getting lost before the
.filter() is returning? The alternative seems to be that the same SQL query is
returning different results, which seems equally bizarre. (There is no
configuration option to change what collation is used for the query, which is
all I could think would change the result as you have described -- Django
always
uses the default collation.)Karen
>
>
> --~--~---------~--~----~------------~-------~--~----~
> 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 <at>
googlegroups.com To unsubscribe from this group, send email to django-
users+unsubscribe <at> googlegroups.com For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Apologies for the long silence before responding. Although I do not recall if
this was the precisely the issue (it was a long time ago), I did eventually
hunt
down an accepted bug in Mysql that makes the "in" clause unreliable,
particularly when used in subqueries. The recommended workaround was to replace
with joins, however my preferred solution was to use Postgres, which solved
this
problem and worked a treat. I appreciated your responses - so thank you.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to [email protected].
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.
