[
https://issues.apache.org/jira/browse/HBASE-15583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15933290#comment-15933290
]
stack commented on HBASE-15583:
-------------------------------
bq. Shell we avoid the obscure immutable HTableDescriptor ?
Yes. The idea was when we pass out an HTD, that it would be read-only. We'd do
this in case application/client changed HTD and either expected the HTD change
to ripple through to the cluster or, their change messed up the current
connection because it was operating with an alternate view to what the cluster
was running with.
Lets not change the API to return ImmutableHTD. While that is explicit about
what is being handed back, it is too much work to back-fill.
Could we change the returned type to be ImmutableHTD in Table and Admin leaving
the APIs as they are. If client tries to modify the IHTD, they'll get an
exception the first time they try. The javadoc says we return an immurable
(least I thought it did).
> Discuss mutable vs immutable HTableDescriptor
> ---------------------------------------------
>
> Key: HBASE-15583
> URL: https://issues.apache.org/jira/browse/HBASE-15583
> Project: HBase
> Issue Type: Sub-task
> Affects Versions: 2.0.0
> Reporter: Gabor Liptak
> Priority: Minor
> Labels: beginner
> Fix For: 2.0.0
>
>
> From [~enis] in https://issues.apache.org/jira/browse/HBASE-15505:
> PS Should UnmodifyableHTableDescriptor be renamed to
> UnmodifiableHTableDescriptor?
> It should be named ImmutableHTableDescriptor to be consistent with
> collections naming. Let's do this as a subtask of the parent jira, not here.
> Thinking about it though, why would we return an Immutable HTD in
> HTable.getTableDescriptor() versus a mutable HTD in
> Admin.getTableDescriptor(). It does not make sense. Should we just get rid of
> the Immutable ones?
> We also have UnmodifyableHRegionInfo which is not used at the moment it
> seems.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
