BitShares Forum
Main => Technical Support => Topic started by: monsterer on December 02, 2014, 04:34:39 pm
-
I'm looking at net_delegate_votes in a transaction returned by the RPC call blockchain_get_transaction. It returns data like this:
"net_delegate_votes":[
[
1302,
{
"votes_for":-60000
}
],
which appears to be an array of arrays of objects of different types. My best guess was that this is supposed to be a map and indeed, looking at the c++ side,https://github.com/BitShares/bitshares/blob/82012fac67ec12ed2cdb0f15603d1d49f1a86299/libraries/blockchain/include/bts/blockchain/transaction_evaluation_state.hpp (https://github.com/BitShares/bitshares/blob/82012fac67ec12ed2cdb0f15603d1d49f1a86299/libraries/blockchain/include/bts/blockchain/transaction_evaluation_state.hpp) defined this member as unordered_map<account_id_type, vote_state> net_delegate_votes which is a map.
My question is, shouldn't this be serialised as (the equivalent of) a JSON associative array?
e.g.
"net_delegate_votes":
{"1302":{ "votes_for":-60000}}, ...}
Currently it's hard to deserialise this back into a map.
Cheers, Paul.
-
Unfortunately we cannot do it that way generally. BitShares uses FC which uses generic reflection to handle serialization format.
Thus you end up with a map<Key,Value> being serialized as an array< pair<Key,Value> >
And a pair<Key,Value> is serialized as an array with two values [ Key, Value ]
And the Key/Value are serialized dependent upon their type which could be anything.
If the Key were an object, array, or some other complex type then you couldn't serialize it as a string.
From a binary perspective the serialization is perfectly efficient, but it looks odd from a JSON interpretation of the same serialization.
It is also more efficient to represent the key as an integer rather than a quoted string from a parsing perspective.
-
If the Key were an object, array, or some other complex type then you couldn't serialize it as a string.
From a binary perspective the serialization is perfectly efficient, but it looks odd from a JSON interpretation of the same serialization.
It is also more efficient to represent the key as an integer rather than a quoted string from a parsing perspective.
I'm not sure why you'd want a complex type as a key, that seems to be against the entire ethos of a map.
In terms of efficiency, there are two things to consider: physical speed and development speed. In this case physical speed on the seralisation side is at the detriment of development speed on the third party side, since developers will have to somehow wrangle this data into a map :)
-
What about our development speed ;).
Things are as they are because we used generic code to accelerate development. Now we can eventually consider 3rd parties
-
What about our development speed ;).
Things are as they are because we used generic code to accelerate development. Now we can eventually consider 3rd parties
Does the library you're using support custom serialisation for given types? If so I could take a look into it to see how hard it might be to implement one and then make a pull request if you can point me in the right direction?