79 results found
-
How to reduce reads for static data
I want to ask documentation on how to reduce the number of unnecessary reads. eg. my product data
let query = store.collection("products");
Assuming I have 500 products, one user click on get products = 500 reads ? If 100 users click that function, then all my quota is gone in 1 minute. Is that right?
How can I overcome this.
Please provide a full example. I have seen Mr Duckworth's presentation in a firebase event, but could not see a good example.
1 vote -
Improve performance & speed of client side write
I've used both Firestore and MongoDB's Realm Device Sync. While Firestore works great in terms of scaling, the performance and speed for client side write is far behind realm, especially when client side is doing some batch writes.
Realm uses techniques like data compression and delta sync to reduce the data size when uploading (https://www.mongodb.com/docs/atlas/app-services/sync/details/protocol/), I'd like to see Firestore doing the same and improve the performance of client side batch write.
Also, what I've noticed is that Firestore's client side write performance degrades a lot after some time being offline, this isn't great for apps that would…
5 votes -
The ability too see when an index was last accessed
When a project grows to a certain size, you'll likely have many indexes with associated queries.
However, queries change, or get removed, and currently there's no way to see if an index could be safely removed, after a query is; which would be a great feature.
4 votes -
Security Rules: unique() operator
I am submitting a feature request to introduce a 'unique()' operator in Firestore's security rules, offering a streamlined method to enforce data uniqueness within collections. This operator would not only simplify validation and potentially reduce reads by leveraging Firestore's hidden index table, but also eliminate the need for a separate cloud function, similar to the 'get()' and 'exists()' operations.
Background:
At present, ensuring data uniqueness in Firestore often requires workarounds that are less than optimal and can impact scalability.
Feature Proposal:
The proposed 'unique()' operator would operate much like the 'exists()' operation, but with a focus on reading Firestore's concealed…
15 votes -
Ability to select and copy fields and values in firestore document
Ability to select and copy fields and values in firestore document, more like making everything selectable text.
4 votes -
Firestore Blocking Functions
Blocking functions for Firestore e.g. block writing a document until a certain condition is met
7 votes -
Allow field selections in client sdk's
Let's say I have an orders collection where each document represents a customer order.
I would like to be able to fetch and listen to only the names and dates of all orders and not get the whole document.
This would speed up a lot queries where not all fields are required and save bandwidth for users.
Since selection is already present in some server side SDK's I wonder if this could be enabled with a somewhat manageable effort.
8 votes -
Firestore Index Name
As a Firestore project grows, so do the number of Composite Indexes.
While the fields are visible, being able to name a composite index would allow us to define which specific feature(s) a composite index is tied to, allowing us to remove unused indexes if they're no longer relevant.
8 votes -
Allow updating multiple documents through a query
Many other databases have support for update queries, such as:
- Apply "x" update data to all docs matching "y" query
- Delete all docs matching "x" query
Maybe these queries would only count as 1 write per doc, as opposed to 1 read + 1 write. At the very least they would have better performance.
15 votes -
FieldValue.min() and FieldValue.max()
Currently the Firestore API supports FieldValue.increment() to atomically increment or decrement a numeric value. I propose to add:
FieldValue.max(value): if the provided value is greater than the existing value on the server, then the field on the server takes this value. If it is less than the existing value, then the existing value remains.
FieldValue.min(value): (the opposite) if the provided value is less than the existing value on the server, then the field on the server takes this value. If it is greater than the existing value, then the existing value remains.
These operators should work on numeric fields AND…
12 votes -
Wildcard index exemptions
Firestore automatically indexes all fields in all collections adding to storage size and slowing write performance.
We can add single-field exemptions but we need to list all fields separately and there is a database-wide limit of 200 field exemptions.
In a highly optimised use case we would want to index only specific fields that we know we query on, and just exclude all others.
It's almost like the current behaviour is a database for novices, but we can't optimise for serious production.
We need either a wildcard exclusion, or effectively just a switch/setting that says "only fields with explicit index…
4 votes -
Support array-contains-prefix operator in Firestore
You can build a search index in a Firestore collection by storing an array of search words.
If you query this property using 'array_contains' you get exact matches for your search string.
If you wish to build a prefix search, then you potentially need to store all prefixes of the words you need to index.Assuming that the array-contains is performing some kind of index scan, it would appear that it was possible to create an array-contains-prefix such that:
where('index', 'array-contains-prefix', 'fire')
would match the following documents[
{ index: ["firestore", "database"],
...
},
{ index: ["firebase", "dog"],
...
}…
5 votes -
Way to access tracelog of firestore events (onCreate, onUpdate, onDelete)
One frequent and strange bug we are facing with firestore is the dropping of events when designing large batch onWrite-listeners. This leads to unexpected bugs in production code.
For some reason, when executing say 300 to 1000 onCreates at once, different events seem to drop and are never responded too.
A way to access the tracelog of firestore events (in Stage 1 Cloud functions) would help us debug this problem. It would also help replay event streams in case the database is corrupted due to non-responding to the event streams.
4 votes -
Allow running Firestore queries from console
Running quick queries straight from the console is currently impossible, making it hard to make adjustments DB wide without fiddling with code.
3 votes -
Rules Debugger with Breakpoints
Imagine how cool it would be to have a debugger for my rules, where I can put breakpoints and see what exact data or condition is causing my rules to fail or pass.
Often times I had to spend so much time in trial and error when writing complex rules for my application. If there is a debugger like I mentioned which is more like any other IDE, it would be super easy and a great developer experience.
3 votes -
Rules between Firestore and Realtime Database
We've rules to limit access to data in both firestore and realtime database, but there are requirements where I need to specify a rule of realtime database based on a value in Firestore.
Games are classical examples, I want to store the realtime game data in realtime DB but apply rules to read and write there based on my user and app data in firestore.
Lack of this is either making me use either of the DB or write hard rules in client side (which is not really secure).
5 votes -
A "--no-document-updates" flag for Firestore import
It has happened to me that I accidentally deleted some documents. While you can restore a collection from a backup, there is no option to not overwrite existing data.
This unfortunately makes it impossible to restore accidentally deleted documents, without also affecting other documents that have changed since you last made that backup. The restore would undo lots of changes that happened after the backup was made.
I think a very effective and simple solution could be to allow only injecting those documents from the backup that do not exist in de target collection. So no document is ever overwritten/updated…
3 votes -
DocumentReference join query
Please add a join query to Cloud Firestore. It seems that using DocumentReference for the join would be appropriate.
23 votes -
Feature like RELATE statements
A RELATE statement to adds graph edges between records. Like the convention of vertex -> edge -> vertex or noun -> verb -> noun, enabling the addition of metadata to the edge record.
6 votes -
Futures feature
Values which should be computed only when outputting data, can be stored as futures.
4 votes
- Don't see your idea?