Adar Dembo has posted comments on this change. Change subject: WIP: Expose a way to set "advanced" non-types scan options ......................................................................
Patch Set 4: (1 comment) http://gerrit.cloudera.org:8080/#/c/6624/4//COMMIT_MSG Commit Message: PS4, Line 15: without "polluting" the api and in such a way that we can remove : support for this in the future. I am opposed to introducing an API that's weakly structured in this way. Generally speaking, string-based key/value interfaces like this are attractive to library developers because the perceived cost of adding or removing an API is low. In reality, these APIs are actually more hostile to application developers than their strongly typed equivalents, for several reasons: 1. It's generally harder to figure out what the legal combinations of keys and values are. That is, it's harder to sift through documentation and/or string constants than through a set of well defined and strongly typed functions. 2. If an application tries to use an API that has been removed, the error will surface at run time instead of link (or compile) time. I don't think removing a strongly typed API is any easier or harder than an API like this one: in either case, there must be a well-defined and well-publicized period of deprecation followed by the removal of the API. Now, since I appear to be standing on a soap box, I feel compelled to continue my ranting. I appreciate that Impala is one of a small set of major applications that use Kudu, and as such, I also appreciate that many of our new APIs are driven Impala's use cases. But, I'm getting tired of seeing APIs defined in a sorta-hidden or you-need-to-know-the-undocumented-format kind of way. We wouldn't tolerate short cuts like these if they were proposed on behalf of github.com/someguy/mycooldataapp; we shouldn't tolerate them for a mature application like Impala either. Moreover, we can't assume that users will always deploy Impala and Kudu in some predefined lockstep configuration; these are both Apache projects and users will try whatever combinations they see fit. As such, when we add APIs for Impala, we should intend for them to last forever like any of our APIs, and we should put enough forethought into them to stand by that commitment. -- To view, visit http://gerrit.cloudera.org:8080/6624 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-MessageType: comment Gerrit-Change-Id: I043b6514dc5fc307fc9c94eb41f3ae79796ba273 Gerrit-PatchSet: 4 Gerrit-Project: kudu Gerrit-Branch: master Gerrit-Owner: David Ribeiro Alves <[email protected]> Gerrit-Reviewer: Adar Dembo <[email protected]> Gerrit-Reviewer: Jean-Daniel Cryans <[email protected]> Gerrit-Reviewer: Kudu Jenkins Gerrit-Reviewer: Matthew Jacobs <[email protected]> Gerrit-Reviewer: Tidy Bot Gerrit-Reviewer: Todd Lipcon <[email protected]> Gerrit-HasComments: Yes
