Feature Suggestion: Multiple Query Criteria with Compound Keys

[ZenPylon]

Hi all,
I've seen a couple questions around the web asking about writing queries with multiple criteria, rather than just location-based queries. For example, maybe I want all users that are within 15 miles AND are in college AND are male AND are under 20. I know there's no built-in way to do this, but I suggested a workaround here.

If that seems like a reasonable workaround, maybe it would be a nice addition to the library? You could use an obscure unicode character as the delimiter, and do something like:

geoFire
    .compoundKey('my/geofire/ref')
    .addKey('user_key')
    .addKey('in_college')
    .addKey('gender')
    .addKey('age');
    .setLocation('whatever')

Then, once retrieved from the query, you could do

geoFireKey.split(), which would return something like

{ 
    user_key: 1234567890,
    in_college: true,
    gender: female,
    age: 19
}

Maybe it could even have a filtering function that you set,

geoQuery.setFilterFunction(function(compoundKey) {
    if (compoundKey.in_college === true && 
        compoundKey.gender === 'female' && 
        compoundKey.age === 19) {
        return true;
    }
    return false;
})

Thoughts?

[jwngr]

Thanks for the feature suggestion and starting this discussion. As you seem to be well aware, we are really limited by the fact that the underlying Firebase SDK can only do a query ordered against one thing at a time.

There are a few limitations to your suggestion:

1. It won't actually make the initial GeoFire query any more efficient. You will still pull down all key which match according to the geolocation. We simply don't have the ability to do a server-side query on multiple things at once. So, this is really just some syntactic sugar for something you can already do client-side with your own custom keys.
2. This seems to fall apart as soon as any value in your keys changes. For example, what happens when a user is no longer in college or their age changes? You now need to somehow remove the old key and add a new key. That is going to be a lot of extra overhead.

I think the only real solution to this problem is better querying from the underlying library. Thankfully, the team is working to improve this situation, as it is one of the largest pieces of feedback we get.

[j13n]

Any updates on this @jwngr ? 😃

[jwngr]

I no longer work at Google / Firebase, so I cannot give an update. I'm not sure who owns this repo anymore.