TagManager.usage_for_model returns list instead of queryset about django-tagging HOT 8 OPEN

Yes, it would be great to have this kind of behaviour for the objects managers.

In my case, i wish to have paginated tag clouds and cannot use the generic
object_list for that purpose.

Do you know of any half-decent way to get the necessary GROUP BY statements 
into the
ORM in order to achieve this?

If there isn't one, I think we'll have to hold out for the QuerySet refactor 
landing
in trunk.

The docstring on `TaggedItemManager.get_intersection_by_model` speaks for a few
places at the moment :)

I've written a patch that updates `usage_for_*` to return a queryset object. I 
wasn't trying to add this feature, 
just make `usage_for_queryset` work, as it seemed to be returning a list of 
tags for ALL objects of the same 
type as the passed in queryset, not only objects in the passed in queryset.

I really need this feature for a project I'm working on... specifically the 
example:

Tag.objects.usage_for_model(Item, counts=True).order_by('-count')

Can anyone suggest how I can achieve the same result in the meantime?

Any updates on this issue?  I'm wondering why `usage_for_model` returns a list 
in the first place, rather than a 
queryset...

For anyone interested in a solution to order the tags by count in the 
templates: the
built in django {% regroup %} tag can be used quite effectively.

http://docs.djangoproject.com/en/dev/ref/templates/builtins/#regroup

Scroll down, just above the next section (spaceless tag), and you will see how 
to
order the set. I ended up with this:

    {% regroup tag_list|dictsort:"count" by count as sorted_tags %}
    <div class="portlet" id="tag_list">
        {% for tags in sorted_tags %}
        <h3>Tags</h3>
        <ul>
            {% for tag in tags.list %}
            <li><a href="#">{{ tag }} ({{ tag.count }})</a></li>
            {% endfor %}
        </ul>
        {% endfor %}
    </div>

Any update on this please? This will be a very useful feature.

My patch above still works, but it won't apply cleanly to trunk anymore, thanks 
to r172.

I've attached an updated patch that applies cleanly to 0.3.1.

Disappointed that this hasn't been resolved in over 2 years now. This looks 
like abandonware, with all the issues continuing to pile up.