Ordering results in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

Ordering Firestore query results by a single field

You have a Firestore collection named products with documents containing a price field. You want to retrieve all products ordered by price from lowest to highest.
Which query will return the products correctly ordered by price ascending?

A db.collection('products').orderBy('price', 'asc').get()

B db.collection('products').orderBy('price', 'desc').get()

C db.collection('products').orderBy('price').get()

D db.collection('products').orderBy('price', 'ascending').get()

💡 Hint

Remember that Firestore orderBy accepts 'asc' or 'desc' as direction strings.

Option A uses the correct method to order by 'price' ascending using 'asc'. Option A orders descending, so order is reversed. Option A omits the direction, which defaults to ascending but is less explicit. Option A uses 'ascending' which is invalid and causes an error.

❓ Configuration

intermediate

Ordering Realtime Database results by child key

You want to retrieve all users from Firebase Realtime Database ordered by their age field.
Which query correctly orders the users by age ascending?

A firebase.database().ref('users').orderByValue('age').once('value')

B firebase.database().ref('users').orderByChild('age').once('child_added')

C firebase.database().ref('users').orderByKey('age').once('value')

D firebase.database().ref('users').orderByChild('age').once('value')

💡 Hint

Use orderByChild to order by a specific child key.

Option D correctly orders by the child key 'age' and retrieves the full snapshot once. Option D tries to order by key but passes 'age' which is invalid. Option D orders by value but 'age' is a child, not the value itself. Option D uses 'child_added' event which triggers multiple times, not a single snapshot.

❓ Architecture

advanced

Designing Firestore queries with multiple orderBy clauses

You have a Firestore collection tasks with fields priority (number) and dueDate (timestamp). You want to query tasks ordered first by priority ascending, then by dueDate descending.
Which query correctly implements this ordering?

A db.collection('tasks').orderBy('priority', 'asc').orderBy('dueDate', 'desc').get()

B db.collection('tasks').orderBy('dueDate', 'desc').orderBy('priority', 'asc').get()

C db.collection('tasks').orderBy('priority').orderBy('dueDate').get()

D db.collection('tasks').orderBy('priority', 'desc').orderBy('dueDate', 'asc').get()

💡 Hint

The order of orderBy calls matters and direction must be specified explicitly when descending.

Option A orders by priority ascending first, then dueDate descending as required. Option A reverses the order of fields. Option A orders both ascending by default, not matching the requirement. Option A reverses directions.

❓ security

advanced

Firestore security rules impact on ordered queries

You have a Firestore collection messages with a field timestamp. You want to allow users to read messages ordered by timestamp.
Which security rule snippet correctly allows read access only if the query orders by timestamp ascending?

A allow read: if request.query.orderByField == 'timestamp' && request.query.orderByDirection == 'asc';

B allow read: if request.query.orderBy[0].field == 'timestamp' && request.query.orderByDirection[0] == 'ASC';

C allow read: if request.query.orderBy == 'timestamp' && request.query.orderByDirection == 'asc';

D allow read: if request.query.orderBy == ['timestamp'] && request.query.orderByDirection == ['asc'];

💡 Hint

Firestore security rules use arrays for orderBy and orderByDirection properties.

Option B correctly checks the first element of orderBy and orderByDirection arrays. Option B compares arrays directly which is invalid. Options B and C use incorrect property names or types.

✅ Best Practice

expert

Optimizing Firestore queries with ordering and indexing

You have a Firestore collection orders with fields status (string) and createdAt (timestamp). You want to query orders where status is 'pending' ordered by createdAt descending.
Which approach is best to ensure the query is efficient and does not require manual index creation?

A Query with orderBy('createdAt', 'desc') only and filter status client-side

B Query with where('status', '==', 'pending').orderBy('status').orderBy('createdAt', 'desc') without creating indexes

C Create a composite index on status ascending and createdAt descending, then query with where('status', '==', 'pending').orderBy('createdAt', 'desc')

D Query with where('status', '==', 'pending').orderBy('createdAt', 'desc') and rely on Firestore to auto-create the index

💡 Hint

Firestore requires composite indexes for queries with multiple filters and orderBy on different fields.

Option C creates the required composite index explicitly, ensuring efficient queries. Option C orders by status unnecessarily and lacks index. Option C relies on auto-index creation which may cause runtime errors until index is created. Option C filters client-side which is inefficient and costly.

Practice

1. What does the orderBy method do in Firebase Firestore queries?

easy

A. It deletes documents from the collection.

B. It filters documents based on a condition.

C. It sorts the query results by a specified field.

D. It adds new documents to the collection.

Solution

1. Step 1: Understand the purpose of orderBy

   The orderBy method is used to sort documents in a query result by a specific field.

2. Step 2: Differentiate from other query methods

   Filtering uses where, deleting uses delete, and adding uses add. These are different from sorting.

3. Final Answer:

   It sorts the query results by a specified field. -> Option C

4. Quick Check:

   Ordering = Sorting [OK]

Hint: Remember: orderBy sorts, where filters [OK]

Common Mistakes:

• Confusing orderBy with filtering
• Thinking orderBy adds or deletes data
• Assuming orderBy changes data, not just order

2. Which of the following is the correct syntax to order Firestore documents by the field age in descending order?

easy

A. db.collection('users').orderBy('age', 'desc')

B. db.collection('users').orderBy('age', descending)

C. db.collection('users').orderBy('age', 'descending')

D. db.collection('users').orderBy('age', -1)

Solution

1. Step 1: Recall Firestore orderBy syntax

   The correct syntax uses the string 'desc' for descending order, not 'descending' or other variants.

2. Step 2: Check each option

   db.collection('users').orderBy('age', 'desc') uses 'desc' correctly. Options A and B use invalid strings. db.collection('users').orderBy('age', -1) uses a number which is not valid in Firestore.

3. Final Answer:

   db.collection('users').orderBy('age', 'desc') -> Option A

4. Quick Check:

   Descending order = 'desc' string [OK]

Hint: Use 'asc' or 'desc' strings exactly in orderBy [OK]

Common Mistakes:

• Using 'descending' instead of 'desc'
• Using boolean or numbers instead of strings
• Omitting quotes around 'desc'

3. Given this Firestore query:

db.collection('products').orderBy('price', 'asc').limit(3).get()

Which products will be returned?

medium

A. The 3 products with the lowest price.

B. The 3 products with the highest price.

C. All products sorted by price ascending.

D. 3 random products from the collection.

Solution

1. Step 1: Analyze the query order and limit

   The query orders products by price ascending (lowest to highest) and limits results to 3 documents.

2. Step 2: Understand the effect of limit

   Limit(3) returns only the first 3 documents after sorting, so the 3 cheapest products.

3. Final Answer:

   The 3 products with the lowest price. -> Option A

4. Quick Check:

   orderBy ascending + limit 3 = lowest 3 [OK]

Hint: orderBy asc + limit = smallest values first [OK]

Common Mistakes:

• Confusing ascending with descending
• Ignoring the limit clause
• Assuming random order without sorting

4. You wrote this Firestore query:

db.collection('orders').orderBy('date').orderBy('total', 'desc').get()

But it throws an error about missing indexes. What should you do?

medium

A. Use where() instead of orderBy().

B. Create a composite index on 'date' ascending and 'total' descending.

C. Change 'desc' to 'descending' in orderBy.

D. Remove one orderBy to avoid multiple ordering.

Solution

1. Step 1: Understand Firestore composite index requirement

   Ordering by multiple fields requires a composite index matching the order and directions.

2. Step 2: Identify correct index to create

   You must create a composite index on 'date' ascending and 'total' descending to support this query.

3. Final Answer:

   Create a composite index on 'date' ascending and 'total' descending. -> Option B

4. Quick Check:

   Multiple orderBy needs composite index [OK]

Hint: Multiple orderBy? Create matching composite index [OK]

Common Mistakes:

• Ignoring index creation errors
• Using wrong direction strings
• Trying to avoid multiple orderBy instead of indexing

5. You want to get all users ordered by their score descending, but only those who have score greater than 50. Which query is correct?

hard

A. db.collection('users').orderBy('score', 'asc').where('score', '>', 50).get()

B. db.collection('users').orderBy('score').where('score', '>', 50).get()

C. db.collection('users').where('score', '>', 50).orderBy('score').get()

D. db.collection('users').where('score', '>', 50).orderBy('score', 'desc').get()

Solution

1. Step 1: Understand Firestore query rules for inequality filters

   Range filters like '>' require orderBy on the same field as the first ordering field. Use 'desc' for descending order.

2. Step 2: Check each option

   A uses orderBy('score', 'asc'): ascending, not descending.
   B: where('score', '>', 50).orderBy('score', 'desc'): correct for filtered descending order.
   C: orderBy('score') defaults to 'asc'.
   D: orderBy('score') defaults to 'asc'.

3. Final Answer:

   db.collection('users').where('score', '>', 50).orderBy('score', 'desc').get() -> Option D

4. Quick Check:

   Range filter + first orderBy on field + 'desc' [OK]

Hint: Range filters require orderBy on same field and direction [OK]

Common Mistakes:

• Mismatching orderBy direction with where filter
• Omitting orderBy when using range filters
• Using orderBy without specifying direction