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

fetchFirestoreCollection casting filter types to string #496

Closed
1 task
nerdoza opened this issue Sep 1, 2020 · 1 comment
Closed
1 task

fetchFirestoreCollection casting filter types to string #496

nerdoza opened this issue Sep 1, 2020 · 1 comment

Comments

@nerdoza
Copy link

nerdoza commented Sep 1, 2020

Bug report

CHECKLIST

  • I have reproduced the issue using the example project or provided the necessary information to reproduce the issue.
  • [ x ] I have read the documentation thoroughly and it does not help solve my issue.
  • [ x ] I have checked that no similar issues (open or closed) already exist.

Current behavior:

When creating a filter for a fetchFirestoreCollection request (on Android) and filtering using a number type (primitive number, not string encoded number), the query will always return 0 results because the code in FirebasePlugin.java which converts the filter array into an actual query object casts the value entry as a string primitive automatically.

if (Objects.equals(filter.getString(2), new String("=="))) {
query = query.whereEqualTo(filter.getString(1), filter.getString(3));
}
if (Objects.equals(filter.getString(2), new String("<"))) {
query = query.whereLessThan(filter.getString(1), filter.getString(3));
}
if (Objects.equals(filter.getString(2), new String(">"))) {
query = query.whereGreaterThan(filter.getString(1), filter.getString(3));
}
if (Objects.equals(filter.getString(2), new String("<="))) {
query = query.whereLessThanOrEqualTo(filter.getString(1), filter.getString(3));
}
if (Objects.equals(filter.getString(2), new String(">="))) {
query = query.whereGreaterThanOrEqualTo(filter.getString(1), filter.getString(3));
}
if (Objects.equals(filter.getString(2), new String("array-contains"))) {
query = query.whereArrayContains(filter.getString(1), filter.getString(3));
}

I have not tested this functionality on iOS yet, nor am I well versed enough in Obj-C to tell if this issue will exist on iOS based solely on the code.

Expected behavior:

The query should maintain the primitive number type for the query.

Steps to reproduce:

const collection = 'posts'
const filter = [
  [ 'postAt', '<=', Date.now() ]
]
firebase.fetchFirestoreCollection(collection, filter, (documents: any) => resolve(documents), (error: string) => reject(new Error(error))

Environment information

  • Cordova CLI version: 9.0.0

Other information:
I'm not entirely certain how to resolve this issue cleanly. It doesn't appear that the JSONArray has a way to determine the primitive type (though the JSON syntax does denote this by omitting the quotes around primitive numbers).

Reference: https://processing.org/reference/JSONArray.html

The only way I can see around this would involve additions to the filter object to specify type, which could be a breaking change if not handled correctly.

@dpa99c
Copy link
Owner

dpa99c commented Sep 15, 2020

Value typing isn't something that was handled in the PR which added support for Firestore filters but I've added support for this in the above commit (currently on the dev branch).
It enables an optional valueType element to be specified in the relevant filter arrays which forces the native type to that which is specified.
Since the additional parameter is optional, this does not introduce a breaking change to the plugin API.

@dpa99c dpa99c added the ready for release Something has been implemented and is awaiting release to npm label Sep 15, 2020
@dpa99c dpa99c closed this as completed in 03d0561 Sep 15, 2020
@dpa99c dpa99c removed the ready for release Something has been implemented and is awaiting release to npm label Sep 15, 2020
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

No branches or pull requests

2 participants