Introspection of querysets

[Dan Davis]

I'm wondering two things:

• Is there any non-internals way to know what sort of iterable a queryset is set to do?   Should there be?   Background - users should not write code to look at isinstance(queryset._iterable_class, FubarIterator) because that is a private interface (and it may be code no longer in 2.x, since I'm currently looking at 1.11.x).
• Is looking at query.values_select, query.annotation_select, and extra_select as is done by the ValuesIterable, ValuesListIterable, and FlatValuesListItereable a supported interface?   Is there documentation for this?   Should there be?

Thanks,

-Dan

[Tim Graham]

Could you explain the use case for the code that needs to handle the different types of iterators?

[Dan Davis]

I was thinking of providing a package containing a couple of DRF renderers that work directly from querysets.   DRF Serializers are great when you need to render a hierarchical structure, and/or when you expect to parse a POST body containing the structure.  For returning non-hierarchical results, querysets ought to be fine.   when I attempted to code this up, I realized that I needed for the renderer to know which fields are in the body to write a CSV or XLSX.  I eventually decided that the renderers would assume that their input queryset was a values or values list queryset.

There is also the issue of simply being more DRY within Django itself - multiple Iterables combine list(values_select) + list(annotation_select) + list(extra_select), so a general public function could make that could slightly better.

It isn't too bad to look at _iterable_class - it just is clearly not a public interface.

On Friday, November 2, 2018 at 1:34:07 PM UTC-4, Tim Graham wrote:.

Could you explain the use case for the code that needs to handle the different types of iterators? list

[Adam Johnson]

I have code in my package Django-MySQL that uses the internals of querysets. It’s not so bad to maintain with enough test coverage and ensuring it keeps up to date with the latest Django. The fact the interface is private means that it could change at any time, but practically that doesn’t mean often, and rarely or never in a patch release.

See code in/around 

https://github.com/adamchainz/django-mysql/blob/master/django_mysql/models/query.py

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7f162ffb-b970-4064-87ef-af67fc0da917%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Adam

[Dan Davis]

OK - why borrow trouble. There is plenty to do just maintaining current interfaces, and adding major features - like the new db functions in 2+.