Author Topic: strange serialisation of map in RPC JSON data  (Read 1522 times)

0 Members and 1 Guest are viewing this topic.

Offline monsterer

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?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

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
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline monsterer

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 :)
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

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.   

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline monsterer

I'm looking at net_delegate_votes in a transaction returned by the RPC call blockchain_get_transaction. It returns data like this:

Code: [Select]
"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 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.

Code: [Select]
"net_delegate_votes":
{"1302":{ "votes_for":-60000}}, ...}

Currently it's hard to deserialise this back into a map.

Cheers, Paul.

My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads