Sort and filter field whitelist

[cmerrick]

Although I think the :indices parameter is a well-intentioned way to determine field filtering and sorting, I think it's going to cause more confusion than it solves. What if I have a composite index? What if I use a hashmap rather than a btree? As a user, I'd rather just be able to specify directly which fields should be sortable and which should be filterable. This also allows the code to serve as very clear documentation for allowable parameters.

I suggest we supercede :indices with two new params: :sort-fields and :filter-fields. They are both whitelists, if they are unspecified then no fields are sortable or filterable.

[cmerrick]

cc @bpiel @karstendick

[karstendick]

That makes sense for the current functionality.

We currently only allow sorting on a single field. We could expand that to sort by multiple fields. If we do, should :sort-fields be a collection of collections of keys? E.g.:

:sort-fields [[col1] [col1 col2]]

You could have an index defined on (col1, col2) but not col2 itself.

Would the same go for :filter-fields?

[cmerrick]

That structure makes sense for :sort-fields.

:filter-fields is a bit of a different story. If you want to keep things simple, then if multiple filters are specified you could just AND them together, which would be commutative, so no additional ordering info is necessary.

If you wanted to get fancy, you could allow for a full filtering language with arbitrary groupings of ANDs and ORs. That sounds like a rabbit hole.

[bpiel]

The current behavior is that filters on different properties get AND'd and multiple filters on the same property get IN'd. For example, I believe ?a=1&a=2&b=3 renders to something like: WHERE (aIN (1, 2)) AND (b= 3)

Because you can have db indices on different sets of fields (eg [a] vs [a b] vs [a c]), does that mean we should support being able to specify filter combinations at that level of granularity?