I have a collection where the documents are uniquely identified by a date, and I want to get the n most recent documents. My first thought was to use the date as a document ID, and then my query would sort by ID in descending order. Something like .orderBy(FieldPath.documentId, descending: true).limit(n). This does not work, because it requires an index, which can't be created because __name__ only indexes are not supported.
My next attempt was to use .limitToLast(n) with the default sort, which is documented here.
By default, Cloud Firestore retrieves all documents that satisfy the query in ascending order by document ID
According to that snippet from the docs, .limitToLast(n) should work. However, because I didn't specify a sort, it says I can't limit the results. To fix this, I tried .orderBy(FieldPath.documentId).limitToLast(n), which should be equivalent. This, for some reason, gives me an error saying I need an index. I can't create it for the same reason I couldn't create the previous one, but I don't think I should need to because they must already have an index like that in order to implement the default ordering.
Should I just give up and copy the document ID into the document as a field, so I can sort that way? I know it should be easy from an algorithms perspective to do what I'm trying to do, but I haven't been able to figure out how to do it using the API. Am I missing something?
Edit: I didn't realize this was important, but I'm using the flutterfire firestore library.
A few points. It is ALWAYS a good practice to use random, well distributed documentId's in firestore for scale and efficiency. Related to that, there is effectively NO WAY to query by documentId - and in the few circumstances you can use it (especially for a range, which is possible but VERY tricky, as it requires inequalities, and you can only do inequalities on one field). IF there's a reason to search on an ID, yes it is PERFECTLY appropriate to store in the document as well - in fact, my wrapper library always does this.
the correct notation, btw, would be FieldPath.documentId() (method, not constant) - alternatively, __name__ - but I believe this only works in Queries. The reason it requested a new index is without the () it assumed you had a field named FieldPath with a subfield named documentid.
Further: FieldPath.documentId() does NOT generate the documentId at the server - it generates the FULL PATH to the document - see Firestore collection group query on documentId for a more complete explanation.
So net:
=> documentId's should be as random as possible within a collection; it's generally best to let Firestore generate them for you.
=> a valid exception is when you have ONE AND ONLY ONE sub-document under another - for example, every "user" document might have one and only one "forms of Id" document as a subcollection. It is valid to use the SAME ID as the parent document in this exceptional case.
=> anything you want to query should be a FIELD in a document,and generally simple fields.
=> WORD TO THE WISE: Firestore "arrays" are ABSOLUTELY NOT ARRAYS. They are ORDERED LISTS, generally in the order they were added to the array. The SDK presents them to the CLIENT as arrays, but Firestore it self does not STORE them as ACTUAL ARRAYS - THE NUMBER YOU SEE IN THE CONSOLE is the order, not an index. matching elements in an array (arrayContains, e.g.) requires matching the WHOLE element - if you store an ordered list of objects, you CANNOT query the "array" on sub-elements.
From what I've found:
FieldPath.documentId does not match on the documentId, but on the refPath (which it gets automatically if passed a document reference).
As such, since the documents are to be sorted by timestamp, it would be more ideal to create a timestamp fieldvalue for createdAt rather than a human-readable string which is prone to string length sorting over the value of the string.
From there, you can simply sort by date and limit to last. You can keep the document ID's as you intend.
I have a set of documents where some of them have a child (associtaion type "ecmccontent:content_origin") and some of them don't have such child association. I need a result set of documents without such association, how to do that (in any query language)?
Thank you!
There's no way to query for associations, unfortunately.
What you can do is setup a property or an aspect - at the same time when you create the association - and then query for that property/aspect.
find nodes with a specific child association
How do i search for an attribute present anywhere in the Marklogic database using xquery if i dont know the attribute value? i.e. I want to check if an attribute called 'court' is present in any document in my database.
It seems like the exists function https://www.w3.org/TR/xpath-functions/#func-exists should help: exists(//#court).
Firebase Firestore has a reference type while defining fields of a document which allows us to add a reference to another document via its "Document path".
For example, I have the document animals/3OYc0QTbGOTRkhXeiW0t, with a field name having value Zebra. I reference it in the array animals, of document zoo/xmo5wX0MLUEbfFJHvKq6. I am basically storing a list of animals in a zoo, by referring the animals to the corresponding animal document in the animals collections.
Now if I query a specific document from the zoo collection, will references to the animals be automatically resolved? Will I the get the animal names in the query result? If not, how can I achieve this?
All document queries in Firestore are shallow, meaning that you only get one document in return for each document requested.
References in a document are not automatically fetched - you will have to make subsequent queries using the references in the document to get those other documents on your own.
Same thing with documents in subcollections - they require separate queries.
I want to query cloud datastore and find all records that dont have a property 'foo'
I was looking at the docs, but didnt find anything there.
Any pointers for such query would be appreciated.
You cannot do that with a query. You will have to read all records and check if the property exists in each of those entities and do what's needed.
The documentation states that -
Entities lacking a property named in the query are ignored
Entities of the same kind need not have the same properties. To be
eligible as a query result, an entity must possess a value (possibly
null) for every property named in the query's filters and sort orders.
If not, the entity is omitted from the indexes used to execute the
query and consequently will not be included in the query's results.
Note: It is not possible to query for entities that are specifically
lacking a given property. One alternative is to add the property with
a null value, then filter for entities with null as the value of that
property.