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

Fix #782: Change hard-coded limitations in API's to configurable #1513

Merged
merged 26 commits into from
Mar 20, 2019

Conversation

manikey123
Copy link
Contributor

@manikey123 manikey123 commented Jan 4, 2019

Added the review comments in request #1478 and test case for the api validation

This is wrt issue #782
Part A (Completed): get_account_history_operations -made FC_ASSERT limit configurable
and wrote the testcase for the same

Testcase Scenarios (Completed for PartA) :

  1. created 1 account with higher return limits(200)
  2. created 2 account with higher return limits(200)
  3. No asset_create op larger than id1 with higher return limits(200)
  4. Limited 1 returns 1 result
  5. alice has 1 op returns 1 result
  6. create a bunch of accounts and return set the limit to 125 and the max operation size to higher return limits(125)-- operation is limited by the max-operation-limit tickets:
    get_account_history_operations fails with partial_history and stop at 0 #1490

Part B: get_account_history - Do you want me to proceed with Part2 for get_account_history to make its FC_ASSSERT configurable?
Test cases already present

  1. get_account_history

Part C: Below apis have FC_ASSERT should they be made configurable?
Currently test cases not present. If they need to be implemented would need to know the scenarios

  1. get_grouped_limit_orders
  2. get_asset_holders_count
  3. get_asset_holders
  4. get_account_history_by_operations
  5. get_relative_account_history
  6. get_fill_order_history

@pmconrad
Copy link
Contributor

pmconrad commented Jan 7, 2019

Feel free to continue with B and C.
IMO writing a full-blown test case for the other API calls is beyond the scope of #782. Would be good to check that the configured limit value works in each case though (in the sense that calling the API with a value below the configured limit returns something, possibly an empty result, and that calling it with a value above the limit throws as expected).

@manikey123
Copy link
Contributor Author

Can part A which I completed be merged with the master code
For parts B and C I can make a new PR. ?
@pmconrad @jmjatlanta

@pmconrad
Copy link
Contributor

Code-wise I'd say this can be merged on its own, however, I would like to see a consistent naming scheme for the option names here and in the future PRs. For example, api-limit-<name_of_api_call>. IMO the general purpose of this option becomes clear immediately if you read only the first one or two components of the name.

@manikey123
Copy link
Contributor Author

Added all the remaining parts for the below apis. Plz review
get_account_history
get_account_history_operations
get_grouped_limit_orders
get_relative_account_history
get_account_history_by_operations
get_asset_holders

@pmconrad
Copy link
Contributor

Hint: use rebase -i and a force-push to get rid of the accidentally added file.

@pmconrad
Copy link
Contributor

One testcase is failing in travis. Can't immediately see what's wrong, please check and fix.

@pmconrad
Copy link
Contributor

Argh, you've destroyed the commit history!
Please check if you still have 906beb3 in your repo, then base the whitespace changes on top of that.

@manikey123 manikey123 force-pushed the 782_test_p1 branch 3 times, most recently from 74406e9 to 0d3a779 Compare March 3, 2019 22:31
@manikey123
Copy link
Contributor Author

Please check if you still have 906beb3 in your repo, then base the whitespace changes on top of that.
whatever commit history I could find from my local repo I have commit that. and then committed the required changes over it plz do review

asset_api::~asset_api() { }

vector<account_asset_balance> asset_api::get_asset_holders( asset_id_type asset_id, uint32_t start, uint32_t limit ) const {

vector<account_asset_balance> asset_api::get_asset_holders( std::string asset, uint32_t start, uint32_t limit ) const {
Copy link
Contributor

Choose a reason for hiding this comment

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

why?

Copy link
Member

Choose a reason for hiding this comment

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

This change is already in develop branch. #1272

Copy link
Contributor Author

@manikey123 manikey123 Mar 7, 2019

Choose a reason for hiding this comment

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

it was added after I made the updates for the PR. had to merge the changes for the develop branch

Copy link
Contributor

Choose a reason for hiding this comment

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

This should be handled during the merge, not in advance.

Copy link
Member

Choose a reason for hiding this comment

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

@pmconrad IIRC there was a conflict, fixed by merging develop branch into this branch. IMHO it's the correct approach. Actually, if you check the whole PR diff or the "condensed" merge commit but not the full merge commit, you won't see this change.

Copy link
Contributor

Choose a reason for hiding this comment

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

Merge conflicts should be fixed during the merge.

In this case, some code was c&p'ed from develop, maybe in order to avoid a merge conflict. That's the wrong approach.

I know the accidentally added / removed code doesn't show up in the full PR diff, but I'd like to have a clean and lean history. That's why git rebase -i exists.

Copy link
Contributor

@pmconrad pmconrad left a comment

Choose a reason for hiding this comment

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

Thanks for restoring history. c0a1109 is what I originally approved I believe.

I'm confused by your later commits though. Why do you add tests only to remove them again? If that was an accident, please squash the two commits into one and force-push.

There's an unrelated API change in there, probably also by accident.

@pmconrad
Copy link
Contributor

Thanks. Squashed one too many but that doesn't hurt. ba3a895 is the parent of the abovementioned c0a1109, and a4108e0 include the changes from that.
Now please merge develop and resolve the conflicts.

updated for test case to match the input type of the api after merge with develop branch
Copy link
Contributor

@pmconrad pmconrad 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 now. Thanks for your patience. :-)

@abitmore ?

@abitmore
Copy link
Member

Personally I don't like some coding styles appeared in the code: tabs, long lines (>118 characters), inconsistent indentations/padding/spacing E.G. sometimes no white spaces around = or after ,, trailing white spaces(old code), and etc. The code itself looks fine (I didn't thoroughly check).

@pmconrad
Copy link
Contributor

To be fair, the diff shows some very long lines in the unchanged parts as well.
I expect the complete codebase will be reformatted in the context of #1318 anyway, so I don't think it will pay off now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants