-
-
Notifications
You must be signed in to change notification settings - Fork 735
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
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -19,6 +19,15 @@ | |
|
||
/** package */ class ParseRESTQueryCommand extends ParseRESTCommand { | ||
|
||
/* package */ final static String KEY_ORDER = "order"; | ||
/* package */ final static String KEY_WHERE = "where"; | ||
/* package */ final static String KEY_KEYS = "keys"; | ||
/* package */ final static String KEY_INCLUDE = "include"; | ||
/* package */ final static String KEY_LIMIT = "limit"; | ||
/* package */ final static String KEY_COUNT = "count"; | ||
/* package */ final static String KEY_SKIP = "skip"; | ||
/* package */ final static String KEY_TRACE = "trace"; | ||
|
||
public static <T extends ParseObject> ParseRESTQueryCommand findCommand( | ||
ParseQuery.State<T> state, String sessionToken) { | ||
String httpPath = String.format("classes/%s", state.className()); | ||
|
@@ -41,38 +50,41 @@ public static <T extends ParseObject> ParseRESTQueryCommand countCommand( | |
HashMap<String, String> parameters = new HashMap<>(); | ||
List<String> order = state.order(); | ||
if (!order.isEmpty()) { | ||
parameters.put("order", ParseTextUtils.join(",", order)); | ||
parameters.put(KEY_ORDER, ParseTextUtils.join(",", order)); | ||
} | ||
|
||
ParseQuery.QueryConstraints conditions = state.constraints(); | ||
if (!conditions.isEmpty()) { | ||
JSONObject encodedConditions = | ||
(JSONObject) encoder.encode(conditions); | ||
parameters.put("where", encodedConditions.toString()); | ||
parameters.put(KEY_WHERE, encodedConditions.toString()); | ||
} | ||
|
||
// This is nullable since we allow unset selectedKeys as well as no selectedKeys | ||
Set<String> selectedKeys = state.selectedKeys(); | ||
if (selectedKeys != null) { | ||
parameters.put("keys", ParseTextUtils.join(",", selectedKeys)); | ||
parameters.put(KEY_KEYS, ParseTextUtils.join(",", selectedKeys)); | ||
} | ||
|
||
Set<String> includeds = state.includes(); | ||
if (!includeds.isEmpty()) { | ||
parameters.put("include", ParseTextUtils.join(",", includeds)); | ||
parameters.put(KEY_INCLUDE, ParseTextUtils.join(",", includeds)); | ||
} | ||
|
||
// Respect what the caller wanted for limit, even if count is true, because | ||
// parse-server supports it. Currently with our APIs, when counting, limit will always be 0, | ||
// 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)); | ||
} | ||
|
||
if (count) { | ||
parameters.put("count", Integer.toString(1)); | ||
parameters.put(KEY_COUNT, Integer.toString(1)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The default There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Actually, we don't need to fetch any objects when counting, right? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
} else { | ||
int limit = state.limit(); | ||
if (limit >= 0) { | ||
parameters.put("limit", Integer.toString(limit)); | ||
} | ||
|
||
int skip = state.skip(); | ||
if (skip > 0) { | ||
parameters.put("skip", Integer.toString(skip)); | ||
parameters.put(KEY_SKIP, Integer.toString(skip)); | ||
} | ||
} | ||
|
||
|
@@ -83,7 +95,7 @@ public static <T extends ParseObject> ParseRESTQueryCommand countCommand( | |
} | ||
|
||
if (state.isTracingEnabled()) { | ||
parameters.put("trace", Integer.toString(1)); | ||
parameters.put(KEY_TRACE, Integer.toString(1)); | ||
} | ||
return parameters; | ||
} | ||
|
There was a problem hiding this comment.
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 to0
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
http://docs.parseplatform.org/rest/guide/#counting-objects
There was a problem hiding this comment.
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 andParseRESTQueryCommand
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 uselimit = 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 thecount()
methods. The issue was thatParseRESTQueryCommand
was ignoringlimit = 0
imposed byParseQuery
.There was a problem hiding this comment.
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.