-
Notifications
You must be signed in to change notification settings - Fork 38
Snapshot for orderbook updates #50
Comments
Hi @cmollen and welcome! With regards to your last paragraph, this only applies when you subscribe to market updates, if you subscribe to the order book or executed trades, then the specific ticker is invoked. |
Thanks for the quick reply, all clear! I would assume that my use case is more common (wanting to capture and store the orderbook for future recreation, without wasting space on levels that haven't changed), but the change was minimal so I will just keep my own branch then. |
If you want to keep a live orderbook you should use subscribe_to_orderbook. With respect to the wasting space on levels, I don’t completely understand what you mean :). |
:) I don't want to keep a live orderbook, I want to store the orderbook to disk and be able to recreate it at a later time for analysis and backtesting. If I store every update passed to the on_orderbook() callback to disk, I will be wasting disk space as it passes all levels of the orderbook, and not just the levels that have been updated. So if I subscribe to 50 levels and only one is updated, I still need to save 50 levels, or check every single update to see which levels have changed. |
With |
As stated in the first post, the only thing lacking with |
I agree that the option of requesting a full order book snapshot to be implemented, but don’t agree that it should be part of the update method. Although in your case it applies, it should be made general. I could implement it as a new method. |
That would be much appreciated. If you want to keep the number of callback methods down, one suggestion for making it more general would be to augment each level of the snapshot with a |
First, thanks for sharing @slazarov.
When subscribing to orderbook updates with subscribe_to_orderbook_update(), there is no snapshot syncing performed. A reasonable behaviour would be that the first update includes all levels.
I have hacked around this (at the expense of subscribe_to_orderbook()), but wouldn't mind contributing with a pull request with a more sustainable solution. Currently, the snapshot is quite heavily tied in with SUB_TYPE_ORDERBOOK, even though the overlap between the two subscriptions types seem to be quite large. How do you feel about consolidating the two types and having a variable (e.g. self.tickers.list[ticker][SUB_TYPE_ORDERBOOK]['IsDifferential']) indicate if only changed levels should be passed to the callback function?
On a sidenote, I can't figure out where in the code the client tells Bittrex which tickers are of interest. Do they simply publish updates for all tickers, leaving the client to filter out tickers of no interest?
The text was updated successfully, but these errors were encountered: