M1L12 : Compound Queries

Lesson 12 of Module 1 of the CWC+ iOS Database course covers compound queries. This is something I used all the time with MySQL / MariaDB.

I’m rather bemused to discover that we can’t actually do compound queries “as-is”. We have to create them outside of the code first. Either we do it through the Firestore web panel or, and this is apparently the prefered route, we create it in Xcode, wait for it to fail, then use a link provided in the failure report to get Firebase to create the query index – this has, so far, taken several minutes.

I’m bemused because I recently pondered why it is that we’re relying on Google Firebase for Apple App Development when it would prove beneficial to not be tied to a specific provider and now we discover that we should actually be relying on error messages to create something that should be part of the system already. I didn’t need to rely on error messages from the provider when I used MariaDB / MySQL.

This seems … bizarre, to say the least. The “way to create compound queries” is to force an error and wait for Google every time we want to create one? Especially as it’s back to throwing up the additional connectivity error I posted about before.

Oh boy… I suppose this is the price we pay for relying on a proprietary system provided by a third party that we have no control over.

A short while later in the tutorial, we learn that we’re only allowed to create a limited number of these compound queries, due to the overhead on Google‘s side. More and more I’m wondering why we’re using Firestore at all. The price for the “ease” at which we can add / edit / delete is mounting up all the time, a price that was never relevant when using MySQL / MariaDB hosted on my own server.

The “challenge” for this lesson is to create more of these compound query indexes in the manner previously shown but now, knowing that there’s only a limited number that Google will let me create, I’m wondering if I should do the lessons or not. I don’t want to squander that limit, and sacrifice future requirements.

Someone decided that Firestore was the best way to do iOS databases, after realising all of this?

let db = Firestore.firestore()
let myCollection = db.collection("collection-name")
let myQuery = myCollection
    .whereField("name", in: ["Dave", "Sue"])
    .whereField("people", isLessThan: 8)
myQuery.getDocuments { querySnapshot, error in
    if let querySnapshot = querySnapshot {
        for doc in querySnapshot.documents {
            print(doc.data())
        }
    }
}

When first run, the Xcode console will show an error such as this:

2022-04-18 17:16:42.368943+0100 Firebase Demo[10143:230924] 8.15.0 - [Firebase/Firestore][I-FST000001] Listen for query at reservations failed: The query requires an index. You can create it here: https://console.firebase.google.com/massively-complicated-url-youll-have-to-copy-and-paste-because-youll-never-be-able-to-type-it-in

On visiting the URL, you can create the index required to execute the query:

1. Click ‘Create Index’ for Google Firebase to do its magic…
2. Expect to be doing some thumb-twiddling whilst waiting for the index to build.

Once Google has done their magic at the Firebase end, you can run the query again and, this time, you should get a result not an error.

It’s okay to reuse the query with different parameter values, without having to go through this again but, each time you need a different query you’ll need to set it up again and it’ll be taken out of the limited number Google allows you to do. I guess they would rather we paid for more of them.

I guess I’m just so used to NOT having a query ceiling or price requirement when I wrote them for MySQL / MariaDB that I’m having difficulty understanding why this is the prefered method for Apple App Development..