Closed agateblue closed 8 years ago
I think one way to achieve this is to follow django's implementation and internally use Q
objects to represent query arguments. Each queryset could then be reduced to a list of Q objects, and when evaluation would be need, values would be populated using these objects as matchers, meaning we iterate only once.
Nice! While using Q objects may seem like overkill, something like this would have the advantage of enabling "advanced queries" such as supporting advanced filters with operators like these
~Q(foo=bar)
Q(foo=baz) | Q(foo=bar)
Q(Q(foo=baz) | Q(foo=bar)) & Q(foo=spam)
- this is a single Q objectInternally, Q objects could be visualized as a dictionary of filter parameters, and can even be de/serialized as such. I did something similar here.
I agree it may seems overkill right now, but I also think we should not reinvent the wheel and reuse existing implementations (such as Django's) to solve this issue.
Handling complex OR/AND queries as you described would definitely be great stuff!
I'started the work on this feature, the first part being using Q
-like objects internally.
This was also fixed in #23
This would lead to a serious performance improvements if querysets where lazily evaluated and all queries where combined in a single one before iterating on values.
This was first raised on reddit: