[
https://issues.apache.org/jira/browse/HBASE-2036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12790385#action_12790385
]
Dave Latham commented on HBASE-2036:
------------------------------------
Enis: It would definitely be more efficient if we cache the hash code. Can we
assume that no one will modify the Configuration after it's already been used?
It seems the existing code already makes that assumption, so it's probably safe
to stick with that.
Stack: I agree, an internal ConfigurationKey would probably be a good idea.
I'd rather have it cache the hashcode than use the object id, so that identical
Configurations will work. For example, if you do a new HTable("tableName"), it
automatically instantiates a new HBaseConfiguration.
> Use Configuration instead of HBaseConfiguration
> ------------------------------------------------
>
> Key: HBASE-2036
> URL: https://issues.apache.org/jira/browse/HBASE-2036
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: Enis Soztutar
> Attachments: hconf.patch
>
>
> HBaseConfiguration extends Configuration but does not add any functionality
> to it. The only function is hashCode() which really should be refactored into
> Hadoop Configuration.
> I think in all the places(especially in the client side) HBase methods and
> classes should accept Configuration rather than HBaseConfiguration. The
> creation of the configuration with the right files (hbase-site and
> hbase-default) should not be encapsulated in a private method, but in a
> public static one.
> The issues has arisen in our nutch+hbase patch for which we include both
> nutch configuration and hbase configurations. Moreover people may want to
> include separate project-specific configuration files to their configurations
> without the need to be dependent on the HBaseConfiguration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
