Reserve 'distinct' query parameter

[daurnimator]

For #915

[ruslantalpa]

i don't see the point in this PR.
it's not like it will warn users not to use this keyword, it will just silently drop it from consideration leaving users to wonder what's going on.

In addition to that, it was not decided that a reserved keyword is the way to go here,
distinct is not on the same level as select/where/from/order ... this is something that is a modifyer in the select part.

[daurnimator]

distinct is not on the same level as select/where/from/order ... this is something that is a modifyer in the select part.

distinct is a sql reserved word in every sense see https://www.postgresql.org/docs/current/static/sql-keywords-appendix.html

[ruslantalpa]

this is not what i was saying, distinct operates in the SELECT space, it does not stand on it's own like WHERE/GROUP/ORDER.

i.e. the place for this feature in in the &select=...distinct... space, and not a top level keyword

[daurnimator]

i.e. the place for this feature in in the &select=...distinct... space, and not a top level keyword

I disagree, as noted in #915 (comment) we need to be able to provide an optional value for distinct and as a matter of http api taste, I think this belongs at the top level.

[ruslantalpa]

and what will you do when the next logical request will be "i need to request distinct entities on the embedded entities"? :)
and i don't see any problems with the value you are saying, it's even more natural
select=distinct(id),name,subitems(distinct(id),name)

[daurnimator]

and i don't see any problems with the value you are saying, it's even more natural
select=distinct(id),name,subitems(distinct(id),name)

Sure; that works too. Though it does look quite a lot like a resource embedding.

[begriffs]

I agree with Ruslan here that disregarding a parameter without raising a warning, and not acting on it in any other way, could really leave people scratching their heads.

Also the first item feels more cohesive to me than the second in this list:

• ?select=distinct(id),name,subitems(distinct(id),name)
• ?select=id,name,subitems(id,name)&distinct=id,subitems.id

Although I admit that this may be purely subjective. Perhaps we'll find that one way is easier to parse than the other and that might influence our choice (as daurnimator pointed out distinct(foo) looks a lot like subitem(foo))

In any case, I'm closing this pull request as-is because until we act on the distinct param I believe it's confusing to silently remove it.