Back to Yahoo! Mail Web Services API Forum
0

Mid Changes Depending Upon Select

If I do a search from ymail.messages for just the items in the sent folder, I get back a list of messages, one of them is as follows.

{
      "mid": "2_0_0_2_4471_ALjSi2IAAQ2DUOWwXg4yHwvXzdM",
      "flags": {
       "isReplied": "0",
       "isFlagged": "0",
       "isRead": "1",
       "isDraft": "0",
       "isForwarded": "0",
       "isHam": "0",
       "isSpam": "0",
       "inAddressBook": "0",
       "hasAttachment": "1",
       "isRecent": "1"
      },
      "from": {
       "name": "--",
       "email": "--"
      },
      "toEmail": "--",
      "subject": "BBB",
      "mimeType": "multipart/mixed",
      "mimeMsgId": "<nX pHgMnFnZA>",
      "receivedDate": "1357230174",
      "size": "955844"
     }

Yet if I do a select using a query in which this message matches, like below:

select messageInfo from ymail.messages where query = "BBB"

I get back a message with a different mid. Below you can see the result of that query is the same message, but with a slightly different mid. Here is the same message that resulted from the query.

{
     "mid": "2_5_22_2_4471_ALjSi2IAAQ2DUOWwXg4yHwvXzdM",
     "flags": {
      "isReplied": "0",
      "isFlagged": "0",
      "isRead": "1",
      "isDraft": "0",
      "isForwarded": "0",
      "isHam": "0",
      "isSpam": "0",
      "inAddressBook": "0",
      "hasAttachment": "1",
      "isRecent": "1"
     },
     "from": {
      "name": "--",
      "email": "--"
     },
     "toEmail": "--",
     "subject": "BBB",
     "mimeType": "multipart/mixed",
     "receivedDate": "1357230174",
     "size": "955844",
     "folderInfo": {
      "fid": "%40S%40Search",
      "name": "@S@Search"
     },
     "sourceFolderInfo": {
      "fid": "Sent",
      "name": "Sent"
     },
     "searchinfo": {
      "snippets": "^_BBB^_",
      "matchedFields": [
       "body",
       "subject"
      ]
     }
    }

It looks like the first segment of the mid is being generated according to some logic which causes it to vary depending upon the select. Pretty obviously, this is screwed and hoses up the ability to rely on the mid when using a query. Any help would be greatly appreciated as this sure seems to be a material bug in YQL and mail usage.

by
Report Abuse
7 Replies

  • I've met with the same issue, and I fully agree with the post author, that message ID (in any case) should not only represent a unique unit, but should also stay static, so that I could refer it later. But I think that the reason for the kind of implementation is not so obvious: it's definitely not a bug. It's intended to be like that, the only question is: why?

    Report Abuse
    0

  • Does anyone from Yahoo even check this forum? Looking through the forum, there is little to no activity from Yahoo in support of developers. The level of support from Yahoo for the developers who seek to bring business to Yahoo is beyond dismal.

    Report Abuse
    0

  • I believe Serhiy responded to you on this. mid here is not a immutable id for the mailbox. Yes it varies depending on the select and thats for some optimization for fetch. However I agree we should have a immutable id for a message which doesn't change but unfortunately we dont have that now. Regarding support, this forum is definitely monitored though only for dev queries.

    Report Abuse
    0

  • Having a mutable mid causes your API to break all over the place. The only way that the API gives to manipulate messages is via the mid. The value of your API is greatly reduced by having no unique mechanism of message identification. In my use, so far, only the Search calls end up with a modified mid.

    Can you at least pass along the logic by which mid is changed so that we can account for it on our side of API access? Without it, your search API is effectively useless as there is then no way to get back to the actual message.

    Report Abuse
    0

  • Having a mutable mid causes your API to break all over the place. The only way that the API gives to manipulate messages is via the mid. The value of your API is greatly reduced by having no unique mechanism of message identification.

    Mutable mids are there for a purpose where no state is required on the client side. I believe its your requirement to have immutable mid because you are saving it for some purpose which is fine but mids are not designed for that. One way would be to use the last part of the mid as unique id but I don't recommend that and will break in the long run when we change something on our side. You can also hash few metadata fields and define uniqueness based on that.

    In my use, so far, only the Search calls end up with a modified mid.

    Thats not true. Mids are always mutable and every API will need the latest version of the mid.

    Can you at least pass along the logic by which mid is changed so that we can account for it on our side of API access? Without it, your search API is effectively useless as there is then no way to get back to the actual message.

    For search you should be using the YQL mail search API "http://developer.yahoo.com/yql/console/#h=desc%20ymail.search" and not the SearchMessages endpoint (will be deprecated soon).

    Report Abuse
    0

  • The mutable mids causes your API to break regardless of the client internals. Here is a simple scenario, which has no bearing on client side code and yet would fail every single time.

    1. Call either the SearchMessage endpoint or the YQL directly with "select * from ymail.messages where query=" ""

    2. You get back a messageInfo that contains a mid and a sourceFolderInfo

    3. Now call the GetMessage endpoint using the mid and the sourceFolderInfo.fid previously returned

    GetMessage returns no message because the mid is not seen to exist.

    This issue has nothing to do with client side internals.

    Report Abuse
    0

  • I believe I asked you to use ymail.search table and not the ymail.messages also when you send GetMessage request send it with enableRetry=true in the request param. Thanks

    Report Abuse
    0
Ask a Question

Recent Posts

in Yahoo! Mail Web Services API