django-tagging is not multi-db safe
Hanne Moa
issue http://code.google.com/p/django-tagging/issues/detail?id=233 .
How is one to use as_sql() now with multi-db in?
HM
Russell Keith-Magee
as_sql() is (and has always been) an internal function - it shouldn't
be relied upon as public API for any application. Looking at the
ticket you linked, it appears that django-tagging has been relying on
the internals of sql.Query(), which isn't the best idea from the
perspective of long term code maintainability.
So - how do you use as_sql() under multi-db? Well, as_sql() still
works as a debug tool - you can call as_sql() on queryset.query, and
you will get a string that is indicative of the SQL that will be
executed on the database. However, it won't (necessarily) be bound to
the right database under a multi-db setup.
For anything more complex than debug - it depends entirely on what
you're trying to do.
Yours,
Russ Magee %-)
James Bennett
One doesn't. And, generally, one should be sticking to the stable
release of Django; third-party applications don't tend to offer
guarantees of working with unreleased development code.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Hanne Moa
> On Sat, Dec 26, 2009 at 3:06 AM, Hanne Moa <hann...@gmail.com> wrote:
>> A site using django-tagging will break hard on 1.2 as of today. See
>> issue http://code.google.com/p/django-tagging/issues/detail?id=233 .
>>
>> How is one to use as_sql() now with multi-db in?
>
> as_sql() is (and has always been) an internal function - it shouldn't
> be relied upon as public API for any application.
I've been using as_sql() for debugging myself. Running it without
arguments doesn't work, so how does one discover what arguments to
feed it?
> Looking at the ticket you linked, it appears that django-tagging has been relying on
> the internals of sql.Query(), which isn't the best idea from the
> perspective of long term code maintainability.
Django-tagging have been relying on a lot of manual sql too, much that
must still remain manual. If only() would also affect what is listed
in a GROUP BY I think at least most of the manual sql could be
dispensed with. Heck, I want only() to work that way regardless. I
could dispense with the last manual sql in my own stuff, used to
calculate statistical mode over a column of integers.
HM
Hanne Moa
> On Fri, Dec 25, 2009 at 1:06 PM, Hanne Moa <hann...@gmail.com> wrote:
>> How is one to use as_sql() now with multi-db in?
>
> One doesn't. And, generally, one should be sticking to the stable
> release of Django;
Kinda hard when one wants to experiment to see what needs to change in
order to upgrade to what will become the next stable version :) I'm
not running 1.2 on production code, no.
> third-party applications don't tend to offer guarantees of working with unreleased development code.
Django-tagging have a lot of users though. Maybe the pinax-people will
arrange for a version that is 1.2-safe.
HM
Rob Hudson
> arrange for a version that is 1.2-safe.
Check out django-taggit: http://github.com/alex/django-taggit
Alex_Gaynor
Unfortunately django-taggit isn't multi-db safe, although I'm aware of
this (and have been ever since I wrote it :P). I don't imagine it'll
be difficult to make it work though, the internal poking is fairly
self contained.
Alex