Skip to content

General

General

Categories

  • Hot ideas
  • Top ideas
  • New ideas
  • My feedback

84 results found

  1. We have unstructured data and each document can have different subcollections.
    We want to know get the names of all the subcollections present in a collection.

    Currently we have to iterate over all the documents present in a collection and for each document we are pulling the list of subcollections present in it.
    This process is very resource consuming and slow. We have to fire a query for each document present in the collection.

    Please provide an api something like db.collection("collectioName").listSubCollectionNames();

    2 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  2. While committing a batch to firestore, if a documents breaks one of the security rules, we only receive: Status{code=PERMISSION_DENIED, description=Missing or insufficient permissions., cause=null}
    That doesn't tell me which document in the batch has the issue. Can you add the document path the is causing the error? Potentially in the "cause" field?

    The logic behind this is that we are seeing Crashlytics reports on our android project with these PERMISSION_DENIED errors, and it is near impossible to track it down without more data.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  3. There's currently no way to get the collections existing in a document using the Unity SDK. ListCollectionsAsync exists in the .Net SDK.

    1 vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  4. There is currently no way to filter on reference fields in the Firestore panel of the Firebase console.

    12 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  5. Instead of making us create inefficient solutions/workarounds ourselves, it would be nice if a convenient API was provided for this functionality.

    For example, transfer col1/doc1/col2 and all its children to col1/doc2/col2

    8 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  6. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    5 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  7. 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…

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  8. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  9. 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…

    18 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  10. Ability to select and copy fields and values in firestore document, more like making everything selectable text.

    4 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  11. Blocking functions for Firestore e.g. block writing a document until a certain condition is met

    7 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  12. 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.

    9 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    4 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  13. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  14. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  15. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    1 comment  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  16. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  17. 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"],
    ...
    }

    6 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  18. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  19. Running quick queries straight from the console is currently impossible, making it hard to make adjustments DB wide without fiddling with code.

    3 votes

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  20. 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

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    We’ll send you updates on this idea

    0 comments  ·  Firestore  ·  Admin →
    How important is this to you?

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)
  • Don't see your idea?