-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
INTPYTHON-348 add support for QuerySet.raw_aggregate() #183
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
12a7f2c
to
51ef179
Compare
efdb444
to
a2008bf
Compare
|
@Jibola 🤔 ^ |
@Jibola @timgraham In case it helps, less args to
|
Right. What I meant by "peeking at the first document" is that we can't use |
E.g. something like this?
That works for me along with mongodb-forks/django@1351d2c |
I haven't examined the details, but yea, something like that. Probably it would be a cleaner abstraction to pass a Btw, in any code you copy you can can omit |
a74a224
to
3e6411e
Compare
Co-authored-by: Tim Graham <[email protected]>
1332688
to
ce9cbcf
Compare
Thank you @timgraham @Jibola @WaVEV! 🎉 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Left a comment or two :)
def __init__(self, *args, **kwargs): | ||
super().__init__(*args, **kwargs) | ||
# Protect against annotations being passed to __init__ -- | ||
# this'll make the test suite get angry if annotations aren't | ||
# treated differently than fields. | ||
for k in kwargs: | ||
assert k in [f.attname for f in self._meta.fields], ( | ||
"Author.__init__ got an unexpected parameter: %s" % k | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this init needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is copied from Django's test suite.
def _execute_query(self): | ||
connection = connections[self.using] | ||
collection = connection.get_collection(self.model._meta.db_table) | ||
self.cursor = collection.aggregate(self.pipeline) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: this would be the only thing that gets updated were we to create a raw_find
version if I understand correctly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think so. With some adjustments for the fact that find()
has more arguments (at least filter
and projection
).
Incidentally, that raises the question as to whether raw_aggregate()
should also accept arbitrary **kwargs
to pass to Collection.aggregate()
.
A diff of how the tests added here compare to Django's
raw_query
tests: mongodb-forks/django#12fixes #163