Skip to content

Fix bug in count queries retrieving object data #678

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

Merged
merged 2 commits into from
Jun 3, 2017

Conversation

natario1
Copy link
Contributor

@natario1 natario1 commented Jun 2, 2017

This fixes #495 , an issue with count() queries that were fetching the whole objects as well as the count. I assume count queries will be much faster now.

@codecov
Copy link

codecov bot commented Jun 2, 2017

Codecov Report

Merging #678 into master will not change coverage.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff            @@
##             master     #678   +/-   ##
=========================================
  Coverage     52.62%   52.62%           
  Complexity     1680     1680           
=========================================
  Files           131      131           
  Lines         10120    10120           
  Branches       1409     1409           
=========================================
  Hits           5326     5326           
  Misses         4353     4353           
  Partials        441      441
Impacted Files Coverage Δ Complexity Δ
...src/main/java/com/parse/ParseRESTQueryCommand.java 100% <100%> (ø) 13 <0> (ø) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 657a478...dfa792f. Read the comment docs.

@Jawnnypoo
Copy link
Member

Were you able to inspect the JSON response and verify only the counts being returned now?

@natario1
Copy link
Contributor Author

natario1 commented Jun 2, 2017

@Jawnnypoo yes, now the response is something like { count: 70, results: [] }. Before you would get data for all the 70 objects, parsed and then dropped 😕

@Jawnnypoo
Copy link
Member

Wonder if this has been broken from day one? Good fix 👍

}

if (count) {
parameters.put("count", Integer.toString(1));
parameters.put(KEY_COUNT, Integer.toString(1));
Copy link
Contributor

Choose a reason for hiding this comment

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

The default limit is -1 if not set.
https://github.com/parse-community/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseQuery.java#L347
So, if there is no limit in the query (will be assigned -1), then there should be a logic that sets limit to 0?
parameters.put(KEY_LIMIT, Integer.toString(0));

Copy link
Contributor

@hermanliang hermanliang Jun 3, 2017

Choose a reason for hiding this comment

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

Actually, we don't need to fetch any objects when counting, right?
So, the the limit should always be set to 0 here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Right. But with our exposed APIs in ParseQuery limit is already 0 for count actions https://github.com/parse-community/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseQuery.java#L1300 see other comment

// but that logic is in ParseQuery class and we should not do that again here.
int limit = state.limit();
if (limit >= 0) {
parameters.put(KEY_LIMIT, Integer.toString(limit));
}
Copy link
Contributor

Choose a reason for hiding this comment

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

I think it can be moved back to original logic.
If count is true, always set limit to 0.

Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Your link is a good reference because it says

With a nonzero limit, that request would return results as well as the count.

So parse-server supports counting and finding altogether. We don’t currently support this with our exposed APIs, but we might want one day in the future.
So since parse-server supports it and ParseRESTQueryCommand is a low level interface to reach the API, I think it should allow any limit.
The important thing is that any call to ParseQuery.count() will use limit = 0. And that is already true https://github.com/parse-community/Parse-SDK-Android/blob/master/Parse/src/main/java/com/parse/ParseQuery.java#L1300 :

final State<T> state = copy.setLimit(0).build();

So the logic if (count) limit = 0 is already in the count() methods. The issue was that ParseRESTQueryCommand was ignoring limit = 0 imposed by ParseQuery.

Copy link
Contributor

Choose a reason for hiding this comment

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

@natario1 Thanks for your explanation and I agree your opinion. Moving this logic out would be the minimum modification to fix this issue.

@natario1 natario1 merged commit d8f96ff into parse-community:master Jun 3, 2017
@natario1 natario1 deleted the fix-count-objects branch June 3, 2017 17:50
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.

count operation fetches all the objects.
3 participants