[Database API] list_votes - Shows votes by other accounts

[singhpratyush]

While using the list_votes method, I noticed this unexpected behavior. As seen in the following request, votes by accounts other than curie are also returned (faurntezil here). Also, the date goes back to 2016-11-05T08:21:48 from 2019-01-09T06:44:30.

$ curl -s --data '{"id":1,"jsonrpc":"2.0","method":"database_api.list_votes","params":{"start":["curie","edgaruvm","gently-murder-me-page-1-breakdown"],"limit":10,"order":"by_voter_comment"}}' https://api.steemit.com | python -m json.tool
{
    "jsonrpc": "2.0",
    "result": {
        "votes": [
            {
                "id": 360060112,
                "voter": "curie",
                "author": "edgaruvm",
                "permlink": "gently-murder-me-page-1-breakdown",
                "weight": 701516,
                "rshares": "1476001623333",
                "vote_percent": 5400,
                "last_update": "2019-01-09T05:21:42",
                "num_changes": 0
            },
            {
                "id": 360064765,
                "voter": "curie",
                "author": "kaerpediem",
                "permlink": "the-big-freeze-a-freewrite",
                "weight": 7701,
                "rshares": "32302975458",
                "vote_percent": 120,
                "last_update": "2019-01-09T05:35:15",
                "num_changes": 0
            },
            {
                "id": 360011073,
                "voter": "curie",
                "author": "ireenchew",
                "permlink": "energy-booster-2019-01-09-02-24-30",
                "weight": 19090,
                "rshares": "40033248696",
                "vote_percent": 144,
                "last_update": "2019-01-09T02:52:48",
                "num_changes": 0
            },
            {
                "id": 360030718,
                "voter": "curie",
                "author": "wilhb81",
                "permlink": "myoneyearanniversaryonsteemitsbigiveawayresultsteemitsbi-h7ytrb25h2",
                "weight": 15992,
                "rshares": "33538496922",
                "vote_percent": 120,
                "last_update": "2019-01-09T03:54:51",
                "num_changes": 0
            },
            {
                "id": 360075035,
                "voter": "curie",
                "author": "alimamasstory",
                "permlink": "ulog-15-merry-christmas-part-ii-and-a-random-year-end-521ff47a325b6",
                "weight": 7727,
                "rshares": "32410182253",
                "vote_percent": 120,
                "last_update": "2019-01-09T06:03:00",
                "num_changes": 0
            },
            {
                "id": 360089167,
                "voter": "curie",
                "author": "janicechua",
                "permlink": "w08u7lz0",
                "weight": 15520,
                "rshares": "32548080853",
                "vote_percent": 120,
                "last_update": "2019-01-09T06:44:30",
                "num_changes": 0
            },
            {
                "id": 5721208,
                "voter": "faurntezil",
                "author": "alexeyantonov",
                "permlink": "francodollars-because-us-dollars-are-never-enough",
                "weight": 0,
                "rshares": -80842753,
                "vote_percent": -10000,
                "last_update": "2016-10-07T21:50:18",
                "num_changes": 0
            },
            {
                "id": 7844604,
                "voter": "faurntezil",
                "author": "granizius",
                "permlink": "hi-steemit",
                "weight": "353357086418440",
                "rshares": 80842753,
                "vote_percent": 10000,
                "last_update": "2016-11-05T08:21:48",
                "num_changes": -1
            },
            {
                "id": 40594711,
                "voter": "faurntezil",
                "author": "ecoworld",
                "permlink": "re-ecoworld-1942-2016-72-years-of-nuclear-part-1-20170706t003126910z",
                "weight": 83,
                "rshares": 174122854,
                "vote_percent": 10000,
                "last_update": "2017-07-06T01:07:15",
                "num_changes": 0
            },
            {
                "id": 40618893,
                "voter": "faurntezil",
                "author": "ecoworld",
                "permlink": "re-ecoworld-1942-2016-72-years-of-nuclear-part-1-20170706t003225730z",
                "weight": 83,
                "rshares": 174122854,
                "vote_percent": 10000,
                "last_update": "2017-07-06T03:00:36",
                "num_changes": 0
            }
        ]
    },
    "id": 1
}

I am not able to understand this behavior (in case if it's not a bug). Is it possible to use the list_votes API to query the votes in reverse order (i.e. latest first)?

Please let me know if I need to provide more info.

---

Method documentation - https://developers.steem.io/apidefinitions/#database_api.list_votes

[mvandeberg]

This API call simply exposes our underlying database and allows you to iterate through it via an API call. The reason votes for another account are being returned is because when this was queried, curie's vote on janicechua/w08u7lz0 was their last vote and the next object in the database was a vote for another account.

No, this call does not allow for you to query their most recent vote. In fact, the call does not even guarantee that the last vote seen for a particular author is their most recent. The last vote is the last comment, sorted by comment id. While that means it will always be a recent comment, it does not mean it is the last comment.

If you want user activity based on time, the account history api is a better tool for the job.

I updated the wording on the dev portal slightly to make this nuanced distinction a bit clearer. https://github.com/steemit/devportal/pull/414

[singhpratyush]

Thanks for the response, @mvandeberg. It makes sense.

Currently, I am using the account history API. But an operation such as fetching the latest 50 votes by the account requires iterating through a lot of data which is not relevant. And pagination on the top of it is even more costly - you need to scroll through the results until you reach some permlink and go for the next 50 votes.

The get_account_votes method was also very inefficient. But if it had a pagination parameter, things would become much better.