Make SolrSearch more compatible with Django QuerySet

[tow]

it would be nice to emulate len(), list(), bool(), and exists() appropriately.

Also better behaviour for iterating over large result sets through multiple Solr calls.

[mlissner]

Another problem I'm encountering that could fit under the banner of making things more compatible with Django is the way Sunburnt uses the mx.DateTime library. When this is used, the dates it creates cannot be passed to the date filter[1] in a Django template.

If you try to, you get a "TypeError: integer argument expected, got float."

The easy solutions I've found so far are:

1. Remove the mx library (though this is a dependency elsewhere)
2. Break the import line in dates.py.
3. Post process the dates so that they are converted to normal Python dates rather than mx dates.

[1] https://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=olddocs#date

[rlskoeser]

Some additional comments on making SolrSearch more compatible with / similar to Django QuerySet:

Currently, if you use the slicing functionality (e.g., via Django Paginator), you lose access to important parts of the Solr response other than the actual result documents (e.g., highlighting, query time, etc). I think that a sliced SolrSearch needs to return another SolrSearch, unless you do something that forces it to be converted to a list (e.g., slicing with a step other than 1); I think this is where I was going with the cached results in the initial django pagination code I submitted, although I didn't do it properly (didn't really even use the cached result).

Related to this, I'm thinking that the execute method would kind of go away (or at least be mostly internal/implicit) - like a django queryset, a solrsearch would be automatically executed at the last possible moment when you do something that requires actual data. -- And I think the current slicing code is pretty close to this (although certainly there is caching & optimization that could be done). One problem is that currently the only way to specify an alternate return type is by calling execute (which you can't do if you use Django Paginator). I suggest adding another method called something like construct_as that would allow specifying a return result type without actually executing the search, so it can be chained with any of the other existing filters or options.

[mlissner]

Yes, I'm struggling with this same issue. Would be great if this could work the way you describe. I'm doing a ton of work in my Django view to process the results 20 by 20 so that I can get access to the information I need, and I'm doing things like pushing the get_absolute_url information into my Solr index, since I can't easily access it (without 20 DB lookups) from Solr.