Github user sjbrunst commented on the pull request:
https://github.com/apache/spark/pull/1717#issuecomment-57552179
@tdas The way I understand it, we have two options here. The first is that
we allow users to pass in their own FilterQuery object. That will minimize the
number of methods we need, but comes with the problems you just described.
The second option is to build the FilterQuery as it is in this PR, but that
will require many methods for all the possible parameters one could want. I
have an application that would benefit from the location parameter, which
inspired this PR. I'm sure @ezhulenev has a use for the count parameter. If we
go with this second option, I think it would be best to have one PR that adds
parameters for everything that FilterQuery takes, so if anyone wants to use any
of the other features (such as language or follow), they won't have to submit
another PR that needs extra methods to keep binary compatibility the way this
one does.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
