-
Notifications
You must be signed in to change notification settings - Fork 85
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
Add ESORT/ESEARCH support. #382
base: master
Are you sure you want to change the base?
Conversation
ESORT and ESEARCH are extensions to SORT and SEARCH allowing users to also get the number of messages (COUNT) matching their criteria, the MIN and MAX ids of those messages, and to also only return part of the message ids for more efficient pagination.
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.
Thanks, this is wonderful. Just one question to clear up...
continue | ||
elif bite == b'ALL': | ||
message_bite = six.next(it) | ||
retval[bite + b'_RAW'] = _raw_as_bytes(message_bite) |
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.
Why is the raw value being returned along with the parsed value? Is the parsed version not more useful?
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.
It should be in the docstring - the raw version allows for a small optimisation, as it can be passed on to a subsequent fetch as well (removing the need to serialise again, and the raw version might contain ranges, making for a small size).
I'm not sure if it has any real life benefits, as the serialisation and transport costs will probably be dwarfed by the time it takes the server to construct and send the response, so if you feel it makes the interface too complicated, I can remove it as well. Real life data point: we skipped using the raw version in the end.
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.
What about making each of these values a (to be implemented) "SequenceSet" object which implement __iter__
to yield the expanded message ids and __str__
to provide the original raw set string?
This makes the raw and parsed versions easily available without requiring separate dictionary values for the raw and parsed variants. Yielding message ids instead of generating a list helps to avoid unnecessary memory consumption in the case of large message ranges.
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.
That sounds like a better way to do this, let me find some time to implement that. Besides __str__
I'd prefer __bytes__
as well, except that is a python3 thing, but I can do both. I'll also just fix the imapclient.util.to_bytes
to check if __bytes__
is available and use it.
retval[bite] = _parse_compact_message_list(message_bite) | ||
elif bite == b'PARTIAL': | ||
message_bite = six.next(it)[1] | ||
retval[bite + b'_RAW'] = _raw_as_bytes(message_bite) |
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.
and again
ESORT and ESEARCH are extensions to SORT and SEARCH allowing users to
also get the number of messages (COUNT) matching their criteria, the
MIN and MAX ids of those messages, and to also only return part of the
message ids for more efficient pagination.
Closes #256