Closed haroondilshad closed 4 years ago
This is actually a bit of a complex task which is on my to-do list but won't be seen in version 3.x.x. it'll have to 4.x.x as it requires a complete change in how documents are stored (but hold tight)
Looking forward to this
The current structure also isn't very friendly for adding this to existing collections (where it's not feasible to migrate every document into a subdocument at d
.
Would it be possible for a future version to instead do something like making the geofirestore data the subdocument?
Example:
name: 'My custom document',
address: 'My custom address',
geofirestore: {
g: '...',
l: {...},
}
(love all the work you've put into this so far by the way!)
@alexandergottlieb my intention is to do something almost exactly like that. Work had been keeping me from making any massive changes to the library and to only maintain it atm. I plan on getting back onto it soon though.
I've been working at a new version of geofirestore which is going to simplify the data structure (as well as potentially making a light-weight version of geofirestore). It'll address a lot of the complaints about data structures in geofirestore, but I wont be able to easily or simply add support for multiple geohashes (it'll add more complexity than desired).
Hello, thanks for this wonderful library. I recently switched from geofirex which allowed me to have multiple geo hashes per document which was really handy but in this case it's not very evident on how to do that. The use case here is that a service provider can have multiple addresses and the service provider must appear in the search for all of those addresses.