1

What is the most efficient way to get the emails "read status" after doing list of messages for some search query?

As mentioned in the include extra field question for messages#list there are field options in Google's try api but it doesn't return the results with those fields. May be this is a bug or gmail team didn't add these fields in response for efficiency reasons.

Assuming we can not get any extra fields including labels from messages#list api, what is the best way to get only read status for the list of messages obtained from messages#list api? I want to avoid loading anything other than read status which we get while using "minimal" from get api.

Community
  • 1
  • 1
Mahesh
  • 611
  • 9
  • 16
  • The functionality I am looking is similar to fetchprofile "FLAGS" while using IMAP#fetch which allows me to get labels/read status with the first search result so that its efficient as well as fewer API calls. – Mahesh Sep 13 '14 at 21:00
  • Not sure why a downvote in this question, it seems something everyone will encounter when they move to newer gmail API from original IMAP based search for gmails. – Mahesh Nov 07 '14 at 23:06

1 Answers1

3

If you only need message.id and read/unread status you could do that without ever calling messages.get() and that would be most efficient. Simply make two list() calls, one with "is:unread" and the other "is:read" and that'll provide the info you need.

Alternatively, if you need more than just read/unread status after doing a messages.list(), pass those message.ids to a (batched) messages.get() call with format=MINIMAL (or METADATA or whatnot). You should be able to do that quite efficiently and quickly.

Eric D
  • 6,901
  • 1
  • 15
  • 26
  • 1
    Thanks Eric. All I need for this is n (n=25 usually) most recent emails for the search query and their read status. – Mahesh Sep 13 '14 at 21:16
  • 1
    For n=25, either way should work and be pretty quick. I imagine two message.lists() will certainly scale better as N increases (as those type of label queries are indexed directly in the backend so even doing it for N=1000 should be fine). – Eric D Sep 13 '14 at 21:45
  • 1
    Thanks. This is what I ended up doing: 1. Get n messages with the query. 2. Get n messages with "is:read" and construct n with read status from set from step 1 and step 2. – Mahesh Sep 15 '14 at 06:19