search

ExchangeUnion / xud

Exchange Union Daemon 🔁 ⚡️
https://exchangeunion.com
GNU Affero General Public License v3.0
115 stars 44 forks source link

Save all completed trades to database #608

Closed sangaman closed 5 years ago

sangaman commented 6 years ago

We should store a history of trades made through xud. It should use a new table in the database (trades) and add a row every time an order is filled. I figure this should not be applicable for nomatching mode.

Here's what I'm thinking for columns in this table:

Once this is in place, I'll create a separate issue to implement a ListTrades RPC method.

I also think we might want a LookupOrder method which checks if an order is still live or, if not, tries to find record of it in trades or swapdeals. Also something for a separate issue and PR.

kilrau commented 6 years ago

Agree. Moved to alpha.4 since indeed not relevant for nomatching mode which is our prio rn.

Instead of only pointing to one successful r_hash we could also point to orderID and thus link all failed + the successful swap so multiple rows in https://github.com/ExchangeUnion/xud/issues/562 what do you think? @sangaman

sangaman commented 6 years ago

Yes, altho we could already do that by querying the swapdeals table for a given orderId. In this case I don't think we'd want a foreign key constraint because we could have an orderId that doesn't exist in the swapdeals table, whereas a rHash would have to exist.

However, now that you bring it up, I'm thinking it would probably make sense from a relational point of view to have an orders table to hold order specific data, where orderId is the primary key. This is so we don't duplicate any data like price and also don't allow the possibility for different rows to have different data.

ImmanuelSegol commented 6 years ago

Can I take this? @sangaman

sangaman commented 6 years ago

@ImmanuelSegol Yes but maybe let me just make some database/structural changes first, then you can do the actual implementation of persisting trades, does that sound good to you?

ImmanuelSegol commented 6 years ago

@ImmanuelSegol Yes but maybe let me just make some database/structural changes first, then you can do the actual implementation of persisting trades, does that sound good to you?

Yeah sure.

kilrau commented 6 years ago

Good to go for this one? @ImmanuelSegol

ImmanuelSegol commented 6 years ago

We should store a history of trades made through xud. It should use a new table in the database (trades) and add a row every time an order is filled. I figure this should not be applicable for nomatching mode.

Here's what I'm thinking for columns in this table:

  • orderId
  • localId
  • pairId
  • quantity
  • price
  • matchingOrderId (for the order this was traded against, I'd be open to a different name. there should be a unique constraint for this combined with orderId.)
  • r_hash (if it was swapped, this can also be used as a foreign key to do a join and find other information about the swap such as the peer)

Once this is in place, I'll create a separate issue to implement a ListTrades RPC method.

I also think we might want a LookupOrder method which checks if an order is still live or, if not, tries to find record of it in trades or swapdeals. Also something for a separate issue and PR.

@sangaman @kilrau Im a bit confused should I add the columns described in this issue or are the current columns the final form of this table: makerOrderId takerOrderId quantity

And should I persist the trades after events: peerOrder.filled, ownOrder.swapped, ownOrder.filled where executed ?

sangaman commented 6 years ago

My comment there was just brainstorming, I don't think you should need to make any more changes to the database structure. You'd need to add the orders involved to the orders table and then reference them in the trades table along with the quantity of the trade.

I haven't looked closely into the best time to persist the trades, but it seems like using those events should work.