Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Listorders all #820

Merged
merged 12 commits into from
Apr 20, 2019
Merged

Listorders all #820

merged 12 commits into from
Apr 20, 2019

Conversation

ImmanuelSegol
Copy link
Contributor

Closes #748
When all=false we return only the top 10 orders sorted by best market price.

@ghost ghost assigned ImmanuelSegol Mar 2, 2019
@ghost ghost added the in progress label Mar 2, 2019
@ImmanuelSegol ImmanuelSegol requested a review from sangaman March 2, 2019 10:42
Copy link
Collaborator

@sangaman sangaman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good for the most part. One thing I wish I'd thought of sooner is that I think it would make more sense to have an optional max_results rather than an all field. If it's zero (the default value) we return all orders. This way a caller who wants more than the hardcoded 10 orders can fetch exactly how many orders they want. It should be a simple change from what you have here. Does that make sense @kilrau ?

Also one minor note, we should change the comment for the ListOrders rpc call in the proto file to drop the words "but unsorted" since it no longer applies.

lib/service/Service.ts Outdated Show resolved Hide resolved
lib/service/Service.ts Outdated Show resolved Hide resolved
proto/xudrpc.proto Outdated Show resolved Hide resolved
lib/cli/commands/listorders.ts Outdated Show resolved Hide resolved
@sangaman
Copy link
Collaborator

sangaman commented Mar 4, 2019

If we do go with a max results parameter, I think we should call it limit mainly to match the terminology we use elsewhere but also because it's shorter, but just clarify with a comment that it's the max number of orders to return for each side of the order book.

@kilrau
Copy link
Contributor

kilrau commented Mar 4, 2019

Looks good for the most part. One thing I wish I'd thought of sooner is that I think it would make more sense to have an optional max_results rather than an all field. If it's zero (the default value) we return all orders. This way a caller who wants more than the hardcoded 10 orders can fetch exactly how many orders they want. It should be a simple change from what you have here. Does that make sense @kilrau ?

limit parameter is definitely good idea. My initial motivation for this was to prevent the platform/user from accidentally getting spammed with ALL orders whereas they are only interested in the top 10, 20 to e.g. show these in the UI. Thinking about this again it might not be that crazy important.

Could you clarify your suggestion?
listorders = 10 orders (hardcoded)
listorders 0 = all orders
listorders 20 = twenty orders

or

listorders = all orders
listorders 20 = twenty orders

?

Honestly, the latter might just be the easiest to understand and ok with me.

@sangaman
Copy link
Collaborator

sangaman commented Mar 4, 2019

I'm thinking the latter, zero (which is the default value if you don't specify a value for the parameter) returns all, specifying a limit returns that many.

@kilrau
Copy link
Contributor

kilrau commented Mar 5, 2019

I'm thinking the latter, zero (which is the default value if you don't specify a value for the parameter) returns all, specifying a limit returns that many.

Yep, exactly. Good with you too? And sorry again for changing our minds on that ;)

@ImmanuelSegol ImmanuelSegol requested a review from sangaman March 11, 2019 19:23
Copy link
Collaborator

@sangaman sangaman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to these, could you also fix the Command.spec.ts test by changing "should flatten, format and sort orders" to "should flatten and format orders" and remove all lines referencing expectedFirstRow and expectedLastRow?

lib/cli/commands/listorders.ts Outdated Show resolved Hide resolved
lib/cli/commands/listorders.ts Outdated Show resolved Hide resolved
lib/cli/commands/listorders.ts Outdated Show resolved Hide resolved
proto/xudrpc.proto Outdated Show resolved Hide resolved
test/integration/Service.spec.ts Outdated Show resolved Hide resolved
lib/service/Service.ts Outdated Show resolved Hide resolved
lib/service/Service.ts Outdated Show resolved Hide resolved
lib/utils/utils.ts Outdated Show resolved Hide resolved
@ImmanuelSegol
Copy link
Contributor Author

@sangaman I think there is a bug in the test, could you have a look.

@ImmanuelSegol ImmanuelSegol requested a review from sangaman March 20, 2019 12:22
@kilrau kilrau added this to the 1.0.0-sprint.14 milestone Apr 11, 2019
Copy link
Collaborator

@sangaman sangaman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some more small changes. Re: the test failing, see the top comment from my last review for the steps I think you need to take in Command.spec.ts.

lib/service/Service.ts Outdated Show resolved Hide resolved
lib/cli/commands/listorders.ts Outdated Show resolved Hide resolved
lib/cli/commands/listorders.ts Outdated Show resolved Hide resolved
lib/service/Service.ts Outdated Show resolved Hide resolved
lib/utils/utils.ts Outdated Show resolved Hide resolved
test/unit/Command.spec.ts Show resolved Hide resolved
@sangaman sangaman merged commit 1b78331 into master Apr 20, 2019
@ghost ghost removed the in progress label Apr 20, 2019
@sangaman sangaman added the grpc gRPC API label Apr 20, 2019
@ImmanuelSegol ImmanuelSegol deleted the listorders-all branch April 20, 2019 10:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
grpc gRPC API
Projects
None yet
Development

Successfully merging this pull request may close these issues.

ListOrders all flag
3 participants