Compound filters

[gryphonmyers]

I think there is a gap in the specification: it is not explicitly called out how compound filter values should be interpreted. Given /aura/tracks?filter[title]=Foo&filter[artist]=Bar should the server send all tracks with title matching "Foo" AND artist matching "Bar"? This would be the most intuitive behavior, but it's not specified.

Should clients be provided with a way to specify they want compound filters to be interpreted with an OR operator instead?

Another example: /aura/tracks?filter[artist]=Bar&filter[artist]=Baz. Would this keep the first value? Last value? Array of both? Assuming array, if we assume an array of values is always interpreted with an AND operator, then this specific query makes no sense... (unless wildcards are supported, but that's another issue). But with an OR operator available, this could be useful as it would allow clients to specify a number of desired values with one request.

[sampsyo]

Agreed—and it's certainly related to #18 in that there is a trade-off here between flexibility and simplicity. If we stick with something like the status quo, I'd say the sensible thing is that compound filters should be specified to have "AND" semantics: if you want "OR," you can just run multiple queries.

(However, we can imagine making this arbitrarily complex: you can make the case that we need to support nested Boolean operators like (title is Foo or artist is Bar) and album is Baz. But suddenly we're getting into GraphQL land and there's no obvious way to encode things nicely in a REST style.)

The conflicting/multiple filter thing is a good question too. If it's "AND by default," I do indeed think this query should be considered illegal.

It might be worth looking into what other JSON-API based tools have done for complex filters like this. For example: json-api-dotnet/JsonApiDotNetCore#183

[gryphonmyers]

Agreed—and it's certainly related to #18 in that there is a trade-off here between flexibility and simplicity. If we stick with something like the status quo, I'd say the sensible thing is that compound filters should be specified to have "AND" semantics: if you want "OR," you can just run multiple queries.

(However, we can imagine making this arbitrarily complex: you can make the case that we need to support nested Boolean operators like (title is Foo or artist is Bar) and album is Baz. But suddenly we're getting into GraphQL land and there's no obvious way to encode things nicely in a REST style.)

The conflicting/multiple filter thing is a good question too. If it's "AND by default," I do indeed think this query should be considered illegal.

It might be worth looking into what other JSON-API based tools have done for complex filters like this. For example: json-api-dotnet/JsonApiDotNetCore#183

Hmm interesting ideas in that thread.

?filter[attrA|attrB]=abc|def
?filter[attrA,attrB]=abc,def

This seems fairly consistent with the way JSON-API specifies sorting, however you'd need some way of distinguishing between delimiter characters and values containing those characters. You could encourage / require double percent encoding of filter values, so on the server side it decodes once, parses delimiters, then decodes each delimited value again.

I'm not madly in love with this solution, but it's not terrible either. I'm gonna have a good long think about this...

[govynnus]

My opinion is to prioritise simplicity over flexibility and just say multiple filters means "AND". Maybe that's because I'm not really a 'power searcher', so don't ordinarily find much use for "OR" queries.

Also in relation to this query: /aura/tracks?filter[artist]=Bar&filter[artist]=Baz, my immediate reaction is that it's not invalid but returns no results (same behaviour as beets).

[sampsyo]

Indeed; when I read over my comment from earlier, I found myself disagreeing with my previous self. 😃 It does seem like conflicting "and"-joined queries would most logically just return no results. And filter[artist]=Foo&filter[artist]=Foo should work fine and be equivalent to filter[artist]=Foo alone.