[
https://issues.apache.org/jira/browse/HBASE-1655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731596#action_12731596
]
stack commented on HBASE-1655:
------------------------------
.bq So a byte[] key will work in a TreeMap (and not in a HashMap), but we'd
break the Map contract. Seems better to just use String and HashMap which works
well and satisfies the Map contract.
Looking at the TreeMap equals implementation, yes, it breaks the above contract
for Map.
We're impure (insert lots of sack cloth and ashes, self-flagellation, etc.,
here -- smile).
We are zealous about using byte [] everywhere. As Jon allows above,
client-side, we can relax some.
IMO, we should not be allowing public construction and static methods.
+1 on Singleton to prevent multiple instantiations.
There is no checkstyle (maybe there is one up in hadoop). In general 80
characters per line and two spaces for tab. Anything else we'll take. Don't
worry about it too much.
> Usability improvements to HTablePool
> ------------------------------------
>
> Key: HBASE-1655
> URL: https://issues.apache.org/jira/browse/HBASE-1655
> Project: Hadoop HBase
> Issue Type: Improvement
> Components: client
> Reporter: Ken Weiner
> Assignee: Ken Weiner
> Attachments: HBASE-1655-v2-partial.patch, HBASE-1655.patch
>
>
> A discussion on the HBase user mailing list
> (http://markmail.org/thread/7leeha56ny5mwecg) led to some suggested
> improvements for the org.apache.hadoop.hbase.client.HTablePool class.
> I will be submitting a patch that contains the following changes to
> HTablePool:
> * Remove constructors that were not used.
> * Change access to remaining contstructor from public to private to enforce
> use of the static factory method getPool.
> * Change internal map from TreeMap to HashMap because I couldn't see any
> reason it needed to be sorted.
> * Remove HBaseConfiguration and tableName member variables since they aren't
> really properties of the pool itself. They are associated with the HTable
> that should get instantiated when one is requested from the pool, but not
> already there.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
