BitShares Forum
Main => Technical Support => Topic started by: monsterer on October 22, 2015, 09:01:37 am
-
Calling:
get_account_history monsterer 2 2 1
get_account_history monsterer 2 1 1
get_account_history monsterer 2 1 2
all result in the same data output. Can anyone explain how this is supposed to work?
http://docs.bitshares.eu/api/history.html
Documentation states that stop, limit and start should each affect the data returned, but that doesn't seem to be the case.
-
get_account_history 1.2.29495 1.11.0 100 1.11.0
if you want to truncate to the more recent once you can change the first "1.11.0" into one of the op ids you see in the output"
the max possible number of ops is 100 afaik
-
get_account_history 1.2.29495 1.11.0 100 1.11.0
if you want to truncate to the more recent once you can change the first "1.11.0" into one of the op ids you see in the output"
the max possible number of ops is 100 afaik
Hmm, that results in:
4 parse_error_exception: Parse Error
Couldn't parse int64_t
{}
th_a string.cpp:100 to_int64
-
try with qutotes
get_account_history "1.2.29495" "1.11.0" "100" "1.11.0"
Ref: https://github.com/xeroc/python-graphenelib/blob/master/scripts/monitor-deposits/monitor.py#L28
-
try with qutotes
get_account_history "1.2.29495" "1.11.0" "100" "1.11.0"
Ref: https://github.com/xeroc/python-graphenelib/blob/master/scripts/monitor-deposits/monitor.py#L28
makes no difference :(
-
you can access this only via websocket connection and only after requesting access to the history_api
this will not work with the cli wallet ..
the syntax for the cli wallet is different
it only takes the name and a limit
get_account_history monsterer 10
-
you can access this only via websocket connection and only after requesting access to the history_api
this will not work with the cli wallet ..
the syntax for the cli wallet is different
it only takes the name and a limit
get_account_history monsterer 10
Oh wow, ok. Thanks for the update.
-
Ok, update: got the permissions set up so I can call the history method on the witness, but I'm getting confusing output:
{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.10",20,"1.11.1"]]}
returns 0 results, and
{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.10",20,"1.11.0"]]}
returns 20 results
So, why if I start from operation 0 do I get results, but if I start from operation 1 I get no results?
-
I also noticed that .. and have no answer for you as to the reason for this ..
-
So, why if I start from operation 0 do I get results, but if I start from operation 1 I get no results?
The call returns ops for the given account such that
stop < op.id <= start
except when start is 0, in which case it returns them all. So by using operation 1, you will get no results unless the account you are querying is the account which performed operation 1.
Our API definitely has some rough edges.
-
The call returns ops for the given account such that
stop < op.id <= start
except when start is 0, in which case it returns them all. So by using operation 1, you will get no results unless the account you are querying is the account which performed operation 1.
Our API definitely has some rough edges.
Ok, so start and stop are backwards?
edit: flipping them seems to result in 0 every time...
-
Ok, finally figured out the parameters are not local indices on the account you specify, but global operation indices. However, I'm still seeing odd results:
{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.88751",10,"1.11.96290"]]}
leads to returning op ids 88893, 88846 and 88845, but this following call, which has been tuned to return only those results by exact index range:
{"id":4,"method":"call","params":[2,"get_account_history",["1.2.29495","1.11.88845",10,"1.11.88893"]]}
leads to nothing being returned at all?
-
Have you solved this issue somehow?
-
We have someone testing/documenting this API as well as working on a new API that is easier.
-
We have someone testing/documenting this API as well as working on a new API that is easier.
Thanks .. that sounds great.
But by now I am fairly sure that there is a bug in the call's implementation. Try to get all transactions from an account that has more than 100 or 200 transactions .. you will see
You also made me curious who there is that is testing and documenting the API?
-
This issue has been fixed and the next release should have this API as well as a new, more friendly API.