Support for multiple `OrderBy` queries.

I would like to see the ability to chain multiple OrderBy queries to filter $firebaseArray.
An example is fleshed out here: http://stackoverflow.com/questions/26700924/query-based-on-multiple-where-clauses-in-firebase

Is this anywhere on the horizon for Firebase? My application sorely needs it.

[jamestalmage]

As discussed in the link you referenced:

multiple orderBy() calls will throw an error, because the clients currently give unexpected results

This is a Firebase core issue, and has little to do with AngularFire.

Depending on your dataset, and what you are trying to do, this can be accomplished.

1. If there is NOT a lot of data - pull everything and just sort on the client

   See angular’s orderBy filter.

2. If there IS a lot of data - create synthetic indexes yourself

   On the client side, when you would normally do:

   ref.set({
     firstName: 'John',
     lastName: 'Doe',
     age: 32
   });
   

   ref.set({
     firstName: 'John',
     lastName: 'Doe',
     age: 32,
     firstLastAge: 'john~doe~032',
     lastFirstAge: 'doe~john~032',
     lastAgeFirst: 'doe~032~john',
     // and whatever other ordering you want to index on
   });
   

   Note that I have done a couple things with the generated index values:

   A. I’ve used ~ character as a separator, it is basically the last ASCII character. The goal here is that john~doe will still come after johny~appleseed. If you are allowing users to store characters that are a superset of ASCII you will need to pick a different separator that is lexographically after whatever the highest allowed character is.

   B. I’ve lowercased everything in the indexes. Firebase process orderBy queries lexicographically, this leads to some unexpected results for the uninitiated:

   Original Dataset: [ C, d, A, b ]
   Alphabetically Ordered: [ A, b, C, d ]
   Lexicographically Ordered: [A C b d]
   

   This has everything to do with the byte value of characters (an alphabetical sorting algorithm would be significantly more expensive).

   C. I’ve padded leading 0’s on the age. This allows users to be up to 999 years old. For bigger numbers you need more padding digits.

   As you can already tell, this quickly gets unmanageable if you need to be able to sort LOTS of different ways. You are also creating a bandwidth and storage penalty by creating those, so that needs to be weighed against the bandwidth penalty of option 1 above. This is similar to the exploding index problems you (used to?) run into on an AppEngine datastore. There are good talks on that topic that you should google if you are seriously considering this.

Other Thoughts

1. You will want to write security rules to enforce correct indexes.
2. Only store the indexes you know you need, you can always add future indexes using the REST api.
3. As discussed, this quickly becomes unrealistic. If you want to give users a table with many thousands of entries, and a way to sort on any one of a dozen columns, Firebase may not be the tool you seek.

[karol-depka]

+1