You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've created a couple bots and indexes to track user balances and trade orders (selling or buying requests that users initiated in the Exchange).
The initial idea was to send this data to ES. But I believe it would be better kept under our relational DB, instead.
Create a model for user_balaces (should have the same fields as the data got from XChange api)
Create a model for user_orders (should have the same fields as the data got from XChange api)
Remove the ES indexes i created earlier
Adjust the bots to collect data into the relational DB
Remembering that now it will done in a per-user basis, we need to be careful to keep our exchange API requests under the limit/ quota of each exchange
The text was updated successfully, but these errors were encountered:
@omigongar - I'm considering two methods that we'll use to fetch user-specific data
(1) Low frequency poller: this is what you're doing now. Let's define an application configurable constant that will define a minimum polling period for each user - we can set it to 246060 (1 day period to start with).
It's going to be useful to have a last_updated (date) field in the user_exchange table - it will keep the timestamp of the last time the user data was obtained for that particular exchange.
Each time you poll for transaction history, orders and balances, you'll check this field to know the start_date you're going to pass to XChange API. If last_updated is null you just fetch the entire history. Once the data is totally received for the particular exchange / user, you'll set last_updated to "now".
(2) Fetch data by client request. I'll create a separate issue for this one.
I've created a couple bots and indexes to track user balances and trade orders (selling or buying requests that users initiated in the Exchange).
The initial idea was to send this data to ES. But I believe it would be better kept under our relational DB, instead.
Remembering that now it will done in a per-user basis, we need to be careful to keep our exchange API requests under the limit/ quota of each exchange
The text was updated successfully, but these errors were encountered: