Adar Dembo has posted comments on this change. ( http://gerrit.cloudera.org:8080/12468 )
Change subject: KUDU-2514 Support extra config for table. ...................................................................... Patch Set 2: (2 comments) http://gerrit.cloudera.org:8080/#/c/12468/2//COMMIT_MSG Commit Message: http://gerrit.cloudera.org:8080/#/c/12468/2//COMMIT_MSG@11 PS2, Line 11: Now, we can specify the history max age second of the table by this feature. Could you split this out into a separate patch? It'd be easier to review the "extra config" mechanism and plumbing in isolation, and then to show how it's used to implement a per-table ancient history mark as a second patch. http://gerrit.cloudera.org:8080/#/c/12468/2/java/kudu-client/src/main/java/org/apache/kudu/client/AlterTableOptions.java File java/kudu-client/src/main/java/org/apache/kudu/client/AlterTableOptions.java: http://gerrit.cloudera.org:8080/#/c/12468/2/java/kudu-client/src/main/java/org/apache/kudu/client/AlterTableOptions.java@364 PS2, Line 364: public AlterTableOptions alterHistoryMaxAgeSec(int historyMaxAgeSec) { > How about define API like this? A related question is, if we're going to do this via a more generic key/value mapping, can users define arbitrary keys? Or is there still only a fixed set of keys that is recognized by Kudu? The advantage of the former is that the extra config can be used as an arbitrary key/value store for important metadata, which can enable new use cases. The disadvantage is that now there can be "collisions" between user-specified keys and system keys (e.g. "max age sec"). Moreover, a generic mechanism could be abused and lead to poor performance (i.e. if the extra config is stored in every tablet's superblock, that's a lot of unnecessary replication for some use cases, not to mention that superblocks can get very large as a result). I'm inclined to start simple and only allow system-defined keys. We can open it up to user-defined keys later on, if we think that enables new interesting use cases and can be done in a performant way. I do think that a String/String API (and wire protocol) is more flexible, provided we publish the set of supported keys somewhere. As to your second question, if only system-defined keys are allowed, I don't think TableExtraConfigPB needs to be generic. -- To view, visit http://gerrit.cloudera.org:8080/12468 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: master Gerrit-MessageType: comment Gerrit-Change-Id: I0514507dca95602a97e954d1db464b907e073aae Gerrit-Change-Number: 12468 Gerrit-PatchSet: 2 Gerrit-Owner: Yao Xu <ocla...@gmail.com> Gerrit-Reviewer: Adar Dembo <a...@cloudera.com> Gerrit-Reviewer: Kudu Jenkins (120) Gerrit-Reviewer: Todd Lipcon <t...@apache.org> Gerrit-Reviewer: Yao Xu <ocla...@gmail.com> Gerrit-Comment-Date: Tue, 05 Mar 2019 21:21:19 +0000 Gerrit-HasComments: Yes
