-->
In Fuego’s Query Builder, managing where
conditions is both streamlined and powerful. To add a new condition, simply click the (+) button to set up additional query lines. The available operators include Firestore’s default operators:
<
less than<=
less than or equal==
equal>
greater than>=
greater than or equal!=
not equalarray-contains
array-contains-any
in
not-in
Additionally, Fuego provides extra operators for enhanced querying capabilities:
starts-with
(string starts with)between
(a shortcut for combining >=
and <=
conditions)Fuego also supports OR
conditions, allowing users to combine multiple where
conditions in a single query, returning documents that meet at least one of the specified criteria. This feature provides greater flexibility in building complex queries, such as when you need to retrieve results that satisfy any of several conditions. By using OR
conditions, users can perform broader searches without creating multiple separate queries, making data retrieval more efficient.
It’s important to understand how Firestore handles queries involving non-existent fields. For example, a query with the condition status != "pending"
will not return documents that are missing the status
field altogether. However, documents where status
is explicitly set to null
will be included in the results. This behavior underscores that Firestore queries cannot directly target documents lacking a specific field.
If needed, you can learn how to add missing fields to documents in the Firestore documentation.
Also, the sequence of where
conditions in a query does not affect the result due to Firestore’s query optimization processes. However, it’s important to be mindful of Firestore’s query constraints, such as the inability to use multiple !=
conditions within the same query.
When executing queries involving multiple fields in where
or order-by
clauses, Firestore may require a composite index to efficiently fetch the data.
If such an index is missing, Fuego will display an error message that includes a direct link to create the necessary index in the Firebase console. Simply click the button to open it in your browser. Note that creating an index can take a few minutes, even for empty collections, so you may need to rerun your query after the index is ready.
In Fuego, understanding Firestore’s default behaviors and requirements for sorting and ordering results helps ensure efficient queries:
Default Sorting: By default, Firestore sorts query results by their document ID. This provides a consistent but generic ordering of the data unless specified otherwise.
Ordering with Conditions: When using a range comparison (e.g., <
, <=
, >
, >=
, starts-with
) or a not-equals (!=
, not-in
) comparison, Firestore requires the first order-by
to be on the same field as the condition. Fuego will automatically insert a hint and the necessary order-by
line to comply with this rule. You can still choose whether to sort in ascending or descending order.
Multiple Order-By Clauses: The sequence of order-by
clauses matters when specifying more than one. The first clause takes precedence, affecting how results are presented. Carefully sequence the clauses based on sorting priorities for your analysis or application.
Indexing Requirements: Using multiple fields in order-by
clauses requires appropriate indexes. Without them, Firestore cannot sort the data efficiently, and Fuego will prompt you to create any missing indexes.
The Limit and Offset options control the number of documents returned by a query and allow you to skip a specified number of records, respectively.
The combined value of limit and offset in a structured query must not exceed 10,000.
These clauses are used to define a range of data by specifying start and end points based on document values or positions. This feature is essential for segmenting data views and managing query results.
The Selection feature allows users to specify which fields to return in a query, significantly improving performance by only retrieving necessary data.
Collection Group queries enable users to perform searches across multiple collections that share the same name but are located at different paths within the database. This feature is especially useful for querying related data spread across different locations.
Previous
Interface overviewNext
Shortcuts