edit order id

[zahrarf]

i just add the ability of getting order_id from outside of match engine and the old one acts like counter of order.

[gavincyi]

Not sure if I understand it correctly - why is the string format order id needed, but keeping the order number?

If purely a string format of order id is needed to return to the user, instead being done in the library, a thin layer to convert int to string can be created, e.g. order_id_maps.append(uuid())

The library is a low level package and you can feel free to add thin layer interface in between.

[sghazanfari]

Hi, The purpose of adding an order_id is that we initially insert orders in our database with an order_id and then feed them to the match engine. It's necessary for us to map the outputs of match engine or orders in the order book with the correct entity in our database.

[gavincyi]

The order id is always returned from the matching engine, while I guess your "order id" is actually the client order id in FIX protocol. I'd suggest you first quickly reading through how the tag "ClOrdID" is used, and then making the following changes

• New order requires only the client order ID (you can name is as client_order_id)
• Order responses from the matching engine always include both order ID and client order ID
• Amend / cancel order requires both the original client order ID and (updated) client order ID

The client order ID was not introduced in the first place because

• memory consideration => requires storing all the client order IDs per account in each session to avoid race condition / collusion
• the matching engine is a simple synchronized engine => the orders are not handled in parallelized queues, so the developer can always add a thin layer to map the client order ID and returned order ID if needed

The first point can be worked around by imposing a strong assumption that the client should always implement a thin layer to check the client order ID. Only the latest version of order ID and client order ID is stored per order.

For example, if a user sends an order with ClOrdID = A, then amends it from A to B, and finally cancels the order with an old ClOrdID = A, the matching engine returns order not found, as there is only an order with ClOrdID = B.

Meanwhile, why don't you just proceed with the following thin layer?

• insert orders in our database with an internal order_id
• pick up the orders from database without matching engine order id and send the order to the matching engine in a blocking process
• once the order id is returned from the matching engine, record it back to the database