Settings and activity
21 results found
-
16 votes
Cedvdb supported this idea ·
-
35 votes
-
32 votes
An error occurred while saving the comment -
34 votes
-
40 votes
-
66 votes
-
81 votes
-
86 votes
-
293 votes
-
81 votes
-
11 votes
-
99 votes
-
2 votes
-
499 votes
-
2 votes
-
1 vote
-
63 votes
-
752 votes
-
136 votes
-
107 votes
An error occurred while saving the comment @frank
The documented solution has the following issues:
- request more documents than necessary
- does not allow much flexibility on modelization
- requires multiple parts of the application to be aware that a collection has a geo field.I'd propose something like:
```collection.within(
radius: 1000,
center: position,
latitudeField: 'position.latitude',
longitudeField: 'position.longitude'
)
```This would allow people to not rely on a GeoPoint data type furnished by firebase and be able to rely solely on Json, which is possible currently for other data types and which brings a lot of advantages:
- no need for an additional layer to abstract firebase specifics
- is easier on code generation tools.----
Just to be clear, I advice to not have a special data type on the firestore side for geo queries, keep it json like and deprecate the current geo data type. Have a geo-hash-index opt-in index on the back-end side.
Imo a better alternative would be to wrap the c++ sdk (and therefor making the c++ sdk solid) and have each platform use that.