Please just expose the field name of updateTime and createTime in firestore document for indexing and query

[Thaina Yu]

I think it safe to assume that firestore document always kept updateTime and createTime at the same place as __name__ field that was mentioned in GCP firestore low level API document

Please just expose it so we can index and query firestore document with those field. It very urgently crucial to solve many many problem about reliability of data. Such as making custom indexing in search service or verifying the field for retroactive index

[Alex Dufetel]

Hi Thaina,

One reason we do not expose update and create time in the client SDKs is that this data would be unreliable when offline. You would have no way of knowing that the data is incorrect and any logic based on that data would be unreliable. 

Another reason is that these fields are not indexed, so you would not be able to query on them. These fields are not indexed by default because that would constrain write QPS. Sequential fields don't play well with indexing, all index writes end up on the same index shard, which constrains write speed.

You can use server timestamps to record document creation and update times though : https://firebase.google.com/docs/firestore/manage-data/add-data#update_fields_in_nested_objects

When doing this, just make sure you're not doing this on a collection that has reasonable write rate (~1 write per sec)

Alex

[Dan McGrath]

Hi,

PM on Cloud Firestore here. Definitely something we'd love to do, however that data for those fields is actually created at a lower level in our storage stack then where indexes are managed, which means we currently don't have a method to be able to index it or use it for querying. It's something we have noted interest for though.

Regards,

Dan

On Tuesday, February 13, 2018 at 3:51:26 AM UTC-8, Thaina Yu wrote:

[Thaina Yu]

You reason to not directly expose it and not include it in default query is perfectly fine, but I just want to able to indexed with custom index we created. We can't query with orderby or lessthan/morethan from the default index anyway

And also we don't query timestamp with Equal operator anyway. But it really precious if we could query every timeStamp with inequality operator

The problem is, if we would not have write the field timeStamp in from the start. When we want to update all the document to have a field it missing, or validate all document to have new format, it hardly be possible

Because we don't have a field we could query for it yet and firestore CANNOT QUERY FOR MISSING FIELD (this is very crucial problem that I was contact bug request so many times already)

Suppose I already have 1 million document in the database, with no timeStamp field. And suddenly I want to update all document to have timeStamp field equal to creation time. What should I do?

I can query and batch update all document at most 500 documents at a time. And if I just list all document directly. When I was update half of documents in collection, it might be possible that there would be a new document that has no timestamp slip in with a key lessthan the half of it. While default firestore query just sort everything by the key. I have no reliable state that I could query or list the collection

Not to mention that both createTime and updateTime is already exist in the database like __name__ field that was also always used in every query. But you force us to duplicate that by our own just so we can index it is not efficient and not reliable. We could always rely on creationTime and updateTime of your server that it will update by the server and no one can mess with it unlike other field. So it more practical that we could not modified that field but still can index and query with it

By nature of firebase that we could have client update data in database on their own. There could be a lag in versioning of client logic. Especially in mobile app that might not rollout new version to all device at the same time. It would be better if we don't relying validation with logic for document with index on client

I am fine that you not expose it in our SDK what I said is that you should just expose the name of it so we can put that name at index creation console and query fieldpath

When we want to query data it would not be when it offline anyway

And as I said I think it is already there, just expose the name of it and we could use it now, simple as that

[Thaina Yu]

This is really sad but then it understandable. Thank you very much for your information. Hope those field will come up in indexes level soon

[Thaina Yu]

Alternatively I have propose that we should be able to write onvalidate function with set value. If this feature exist we could just write validate function to set createTime and updateTime when we need to

https://groups.google.com/u/0/g/firebase-talk/c/9IDRwYKEgKw/m/d9LiRBCxAQAJ

[Thaina Yu]

Hello, this was already 2 years. Do we have any progress on this feature?

On Thursday, February 15, 2018 at 3:07:15 AM UTC+7 Dan McGrath wrote:

[Kirill Pertsev]

For some reason these timestamps are exposed in Go client SDK: https://pkg.go.dev/cloud.google.com/go/firestore#DocumentSnapshot

[Sam Stern]

These fields are exposed on DocumentSnapshot objects in the SDKs however they're still not available to query since they are not actual document fields, just metadata. So Dan's original response still holds.

- Sam

--
You received this message because you are subscribed to the Google Groups "Firebase Google Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebase-tal...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0b0f5748-a988-48fe-96ee-826be216a71bn%40googlegroups.com.

[Kirill Pertsev]

This is correct. This thread is one of the top resources for this problem though, and I decided to drop a link here for people searching for a workaround. The workaround (as comes standard for Firestore) is to "do it on the client" and for that we need to have these fields in SDKs. So far I only found it in Go SDK for some odd reason (probably because it's used internally at G)