[
https://issues.apache.org/jira/browse/HBASE-15597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904286#comment-15904286
]
Jerry He commented on HBASE-15597:
----------------------------------
v3 LGTM
{code}
val QUERY_CACHESIZE = "hbase.spark.query.cachesize"
val QUERY_BATCHSIZE = "hbase.spark.query.batchsize"
{code}
{code}
val TIMERANGE_START = "hbase.spark.query.timerange.start"
val TIMERANGE_END = "hbase.spark.query.timerange.end"
val MAX_VERSIONS = "hbase.spark.query.maxVersions"
val MAX_VERSIONS = "hbase.spark.query.maxVersions"
{code}
It is good we use 'query' instead of 'scan' in the context of Spark query.
'cachesize' is named 'cachedrows' in TableInputFormat. Let's follow it?
{code}
/** The number of rows for caching that will be passed to scanners. */
public static final String SCAN_CACHEDROWS =
"hbase.mapreduce.scan.cachedrows";
{code}
Please add some comments on these names if you can.
> Clean up configuration keys used in hbase-spark module
> ------------------------------------------------------
>
> Key: HBASE-15597
> URL: https://issues.apache.org/jira/browse/HBASE-15597
> Project: HBase
> Issue Type: Bug
> Components: spark
> Affects Versions: 2.0.0
> Reporter: Sean Busbey
> Assignee: Yi Liang
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-15597-v1.patch, HBASE-15597-V2.patch,
> HBASE-15597-V3.patch
>
>
> This should be considered a blocker for backport to branch-1 since it will
> impact our compatibility.
> The constants we expose in configuration should all start with "hbase". Since
> our configurations keys for the spark integration all relate to that system,
> the prefix for all configuration keys (excluding those cases where we need to
> do something special due to restrictions in how properties are handled by
> e.g. spark) should be "hbase.spark".
> Before publishing a public api labeled version of our spark integration we
> should review all of our configuration keys to make sure they either conform
> to the "hbase.spark" prefix or they have a comment documenting why they need
> to be otherwise.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
