3 ms·
Mind: - the query language is quite limited (fe, searching on the absence of an attribute is not possible) - shame you can't do projections on the changes
by toolslive 5y ago
Mind:
- the query language is quite limited (fe, searching on the absence of an attribute is not possible)
- shame you can't do projections on the changes server side.
you get the whole thing and not just the fields you're interested in
- rockwotj 5y agoThe query language is limited, but a lot of the limitations are intentional. Here is a post from a while back where I explained some of the reason for some of these limitations; https://groups.google.com/g/google-cloud-firestore-discuss/c/9DT5ZX9EmmM/m/wNyFP259DAAJ https://groups.google.com/g/google-cloud-firestore-discuss/c... Granted not all of them are due to this philosophy and some are just hard problems due to other constraints like the security rules verification system. RE projections: this is actually due to some limitations in processing security rules and not a limitation in the query matching. Edit: RE matching on missing attributes. This is due to Firestore having sparse indexes and being schemaless, if you write explicit null values you can query for those fields being null.
- toolslive 5y agoIf your building a reactive website then firestore is actually great. Edit: but yes IMNSHO, there are also some design mistakes (schemaless, silly limitations on keys, ...) both in the service and the client libs. I only used the python and js clients though. I might be biased
- rockwotj 5y agoYupp, certainly don't disagree. It's not a perfect system - to comment on those two issues: there were some pipe dreams when I was there to support schemas, including partial schemas, but we needed a better migration story (and someone to convince the powers that be it was the right thing to work on). The limitations on keys are mostly due to the system being compatible with Cloud Datastore.