How do we store data?

[ollyde]

Am I missing something big here, I looked at the docs and there's nothing.

How are we suppose to store data with Firestore using this lib exactly?

[MichaelSolati]

So the library expects you to use geofirestore to add data. However if you choose not to there are a few things that are expected...

• The top level of the doc had 3 fields. g, a geohash string in lowercase, l a geopoint, and d the data you want to store.
• When you add a document to a collection, collectionRef.add({ coordinates: new Firebase.firestore.GeoPoint(0, 0) }), the function looks for a field called coordinates (I'm answering on my phone, can't check, but pretty positive) to create a geohash from. However you can pass in a string as a second argument to tell geofirestore what field to use for the location.
• There is a code sample on how to mass add data to a collection in the proper format without using geofirestore that you may like.

[ollyde]

Ok thanks there's no mention of this anywhere in any of the docs.

Btw is there any reason why we need to make the database fields dirty (those single letter vars) or is that optional? (Unlike GeofireX for example which as just 'point' as a field.)

[MichaelSolati]

So this is because the library was more closely aligned to the geofire library for Firebase which depends on the g and l field in order to serve as an index.

As a side note, I slightly prefer this as the logic and fields necessary in order for the library to work are abstracted from the end user (that way there's less conflict between what I'm doing and what you need to do)

BUT I do think I can better explain that in the docs.

[ollyde]

Ah it's not so friendly for other developers who might just open it and wonder why there are single char vars.

Anyhow. I cannot find any cloud functions documentation anywhere for storing the data, can you point me in the right direction? Thanks for the replies.

[MichaelSolati]

I can throw together a little sample, is there something in specific you're looking to do?

[ollyde]

That would be awesome man.

[MichaelSolati]

@voidstarfire I was super busy this past week, but here is a little sample

[ollyde]

Thanks so much you're great! Would be nice if this was in the docs :-)

Just a question, does this modify all the existing data at any point in the future? I have millions of users I'm playing with here so I gotta be super careful (Of course this is executed on backup dev databases when we test but sometimes you never know with libraries.)

[MichaelSolati]

That sample does not modify existing data, only new. You can do something similar with a geofirestore batch id say. It could be interesting to write (but totally doable)

I'm currently focused on writing tests for runTransactions. But before launching that with v3.2.0 I'll update the readme

[ollyde]

Do you mean that new data is created in a GeoFire format or do mean that existing data can be created into new GeoFire data losing the fields or not? 😅

I'll try running a batch on the database, will cost me a $$$ 😂

[MichaelSolati]

Batch should save you some $$$ as it'll allow you to modify up to 500 docs in one write. (Instead of individual writes). And I'm not sure if I understand your question, but the code snippet was to take a non geofirestore doc and turn it into one without losing the data fields (just embed it into the geodoc)

[ollyde]

I got it working but randomly the 'd' field doesn't update or sometimes sub docs only partly update.

Is it possible to skip using the 'd' field and just use the document data? (Which will be the case almost 100% of the time anyhow). There are almost no docs for this library.

Would be nice to run it off just g (geohash) and l (location)?

[MichaelSolati]

So unfortunately the d field is necessary for abstraction and preventing data from being corrupted. Wanna post a snippet/example of how things look for you (some code, some screenshots, hopefully I'd be able to help)

[ollyde]

The data would be corrupted in a read only scenario? Using 'near' for example?

[MichaelSolati]

I'm sorry I'm uncertain of what you mean. Uhm, ideally we wrap all the docs so you never need to worry about the sub document d.

Anyway, what I think you're talking about is using the update function, which requires a flat document. If you need to update sub documents you'd need to use dot notation to target those fields (similar to how firestore does update). If that would be an issue, I'd advise you to use the set function.

[ollyde]

Thanks so much for your help dude. It was was solved by just putting everything in a special 'geofireUsers' collection.

I use set here all the time.

It's working really really fast now. I mean like how.. lol..