Feature: able to set an ID in limit_order_create operation

[rmawatson]

I am trying to traverse historical bitshares data and am having problems with associating fill_order and limit_order_cancel operations to their limit_order_create operations.

Both of limit_order_cancel and fill_order operations contain an order_id field in the json. But historical limit_order_create operations do not. It seems this order_id is only available and returned when the original order is created.

As a workaround I was hoping to use the order_id field in limit_order_cancel and fill_order and get_object() to get the original order. However get_object() returns nothing for 1.7.x type objects (limit order objects). Unless I am missing something, I am basically unable to link these operations.

[oxarbitrage]

ill take a look and let you know what can we do.

[abitmore]

If an order get completely filled or cancelled, it will be removed from the object database, so get_object will return null. The order id is in the result or operation_result field after created.

[rmawatson]

its in the object result when created, but not included with the data stored in the blocks, so given a historical limit_order_create operation and various fill_order and limit_order_cancel (which include the order id in the json) there is no way to correlate them. All that would be needed is that the order_id is added to the stored limit_order_create.

[abitmore]

@rmawatson thanks for the suggestion. It's a good idea, however, it's a blockchain, we can not simply add a field to an existing operation, although not impossible to upgrade the consensus protocol. If you have interest and time, try compose an more detailed solution and submit an issue to https://github.com/bitshares/bsips/, including how to add the field, how to maintain backward compatibility for both the back end and the front end and etc.

[oxarbitrage]

an alternative to BSIP and hardfork can be to make use of WIP elasticsearch objects plugin to go after this issue. i think it is important to have some workaround to make that relation possible. #500

the problem is mainly the 1.7.X objects are removed after a fill cancel or at expiration. similar issue in proposal objects that were already added to that plugin i now added the limit order objects in this commit: fddf08d

with this the 1.7.X will be added to the database and never deleted allowing us to make the relation.

[xeroc]

Assuming create-limit-order ooeration has an extension field, why not use that to allow custom identifier, together with a new index to track object id and custom identifier?

[oxarbitrage]

hmm, i don't think it will be that easy.
when the limit order is created we have nothing to add as there is no cancel neither fill at that moment. update the limit order will mean to add a new operation. maybe i am wrong.

[abitmore]

Assuming create-limit-order operation has an extension field, why not use that to allow custom identifier, together with a new index to track object id and custom identifier?

That's doable. Just a note: making use of extensions field requires a hard fork due to serialization change.

[abitmore]

@sschiessl-bcp shared an article https://hackernoon.com/the-ideal-crypto-trading-api-b1bbb2675875 which indicates a client-decided ID is good.

[xeroc]

So, adding a user-defined order-id would IMHO require

• a hardfork to add the user-defined id to the create_limit_order operation
• an index over user defined order id that maps to object ids
• an API that allows to query for the object id by using the user-defined order id

Doesn't sound too complicated to me

[abitmore]

@xeroc please continue the discussion in bitshares/bsips#185. If have the time / resource, write a BSIP.