SO save orders for visualization purposes

[bitphage]

There was a telegram discussion regarding #609. As I understand, visualization code requires:

• state of initial orders on SO worker
• state of current worker orders

[Jackodb]

It would be very helpful if initial orders and current orders could be kept apart from each other in some way.

[bitphage]

The main proposed solution was to dump orders into database. Along with the described requirements, there are also #442 task to keep virtual orders in state. It's good time to fit everything now.

So basically we have two order types to save:

• initial
• current

Both of these types could also be a real or virtual order.

Current Orders table structure doesn't fit specified requirements. The following changes are needed:

• Add column "Virtual" type bool. True indicates that saved order is virtual
• Add column "Custom" type String to store any custom data, this column could be used by any strategy later. Specifically, SO may store here indicators "initial" or "current"

[Jackodb]

The orders you would dump into database are like the output orders you get when calling Account.openorders right? So I hope that includes things like 'for_sale', 'price', etc. since I need that information in my visualisation plot too (i.e., price, whether it's base or quote).

I like the addition of virtual orders since I prefer plotting all the worker's orders, not only the real ones.

[bitphage]

Yes, the full Order object is dumped.

[bitphage]

Because we're going to modify table structure, we need a way to upgrade existing dexbot installations without breaking database. I'm experimenting with alembic to handle database migrations.

[PermieBTS]

Can this save orders dev also saved virtual order state on restart?
#442

[bitphage]

Yes, it will be integrated. Progress is here https://github.com/Codaone/DEXBot/projects/15