Skip to content
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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open

Add ESORT/ESEARCH support. #382

wants to merge 4 commits into from

Conversation

jap
Copy link
Contributor

@jap jap commented Jul 9, 2019

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

jap added 4 commits July 9, 2019 09:57
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.
Copy link
Owner

@mjs mjs left a 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)
Copy link
Owner

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?

Copy link
Contributor Author

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.

Copy link
Owner

@mjs mjs Jul 14, 2019

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.

Copy link
Contributor Author

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)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and again

@mjs mjs added this to the 2.2.0 milestone Jul 19, 2020
@mjs mjs modified the milestones: 2.3.0, 3.1.0 Jul 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ESEARCH support
2 participants