Settings and activity
21 results found
-
16 votesCedvdb supported this idea ·
-
35 votesCedvdb supported this idea ·
-
32 votesCedvdb supported this idea ·
An error occurred while saving the comment -
34 votesCedvdb supported this idea ·
-
40 votesCedvdb supported this idea ·
-
66 votesCedvdb supported this idea ·
-
81 votesCedvdb supported this idea ·
-
86 votesCedvdb supported this idea ·
-
293 votesCedvdb supported this idea ·
-
81 votesCedvdb supported this idea ·
-
11 votesCedvdb supported this idea ·
-
99 votesCedvdb supported this idea ·
-
2 votesCedvdb shared this idea ·
-
499 votesCedvdb supported this idea ·
-
2 votesCedvdb shared this idea ·
-
1 voteCedvdb shared this idea ·
-
63 votesCedvdb supported this idea ·
-
752 votesCedvdb supported this idea ·
-
136 votesCedvdb supported this idea ·
-
107 votesCedvdb supported this idea ·
An error occurred while saving the comment Cedvdb commented@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.