Document structure and future customization
rahulravindran0108 opened this issue · 4 comments
This is more of a question than a bug. I noticed that the document
needs to follow a specific structure. So, new projects most likely
use firestore as opposed to realtime database. Hence, most use-cases
will try to find a firestore port of geofire on pretty much all platforms.
I'm coming from iOS side and it looks like the implementation there
uses a flat structure like:
g: geohash (String)
l: (lat, long) (GeoPoint)
I'm looking to do the same for the web but this library has a
different structure to it. I do have some work-arounds I can do to save
time but is this a reasonable enough change I can make after forking ?
If so, could you provide a code hint ?
Aside: It looks like from a functionality perspective - two things needed are
the geohash itself and the lat/long as GeoPoint. Why not let them be passed as
custom keys just like the way collection name is configurable ?
In earlier versions of this library (v3, v2, and v1) a similar data structure as geofire was used, where there was a g and l field, but user data was stored in a d object. The user only ever had the d object returned, and never saw the other fields. A reason for that is I didn't want to have multiple fields that a user could manipulate by accident, so I abstracted all the fields the library added. All an user had to provide was the document, the library would put it into the d field, and when they queried the library would only return the d field.
This led to some confusion though, as when a developer would look at the data structure in their collections they'd see the d field and think that they needed to add it to their queries and what not.
The new structure with user data being at the top level and all the geofirestore data being embedded in the g field came after feedback about thed field being confusing as well as me not wanting to have that heavy of an influencein users data. When/if the Firebase team opts to support geoqueries natively then all a developer would have to do is remove the g field. In regards to using a custom key that's defined when you to define a collection, I actually think that's a good idea! I'll probably include that in the next version of the library. (End of the week(?))
Awesome! Once, you have the custom key capability - I believe it would
be much easier to integrate this across platforms. I am unsure when
exactly Firebase would support this natively but for the time being, most
users resort to some of the community led initiates of integrating geofire
with firestore.
Frankly, the swift version isn't being maintained either - So, I spent a day
ripping out that functionality and throwing your library behind a cloud function
to make this work across platforms. Your idea behind abstracting most of the
geohashing related data makes sense and I don't mind closing this out as a
won't do, the only conclusion I could make from looking at other
projects is that from a functionality perspective - you only required those two
fields. Hence, if they were configurable - it wouldn't matter much what they were
called (Assuming the other platforms all base their functionality from geofire).
Hi @MichaelSolati thanks so much for your work on the library. I'm actually using your library in react native, and I just want to know will v3 continue to be maintained with future evolvement in firebase? Example for newer firebase queries? My concerns is that since the data structure is no longer the same in v4 (eg: exclusion of the d field), I cannot simply migrate the data to the v4 format as it will break the app versions (where user have not updated the app) that are still on v3.
Just wanted to seek your thoughts on this, and whether it's still okay to continue staying on v3 of the library, or if data migration is really necessary going long term with this library.
Thanks so much!
@rahulravindran0108 v4.2.0 is releasing nowish which will allow you to define a custom key for geocollections when you define a geocollection, rather than when you add a doc (as well as for geowritebatches and geotransactions).
@robertqin86 I see myself supporting v3 of geofirestore until the end of the year if bugs or security issues arise. As for new features, those will only be added to v4. I'd suggest making a migration in your data structure to your collection (though v3 is in a stable place and shouldn't really break anytime soon). Check out this bit in the README if you need pointers in migrating your data.