[
https://issues.apache.org/jira/browse/HBASE-8372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13639387#comment-13639387
]
Jonathan Hsieh commented on HBASE-8372:
---------------------------------------
So wait, you've asked me to deal with the case where add is called after set,
and I've wrote code making it unsupported. You pointed out a counter example
where that was insufficient, and I added code and unit tests that address that.
Now you are saying the usage of set after an add is unsupported? Please make
up your mind.
*Please provide unit test psuedo-code to demonstrate the semantics you want in
a follow-jira.*
bq. There is no set() call after the add() calls.
In your previous counterexample, with the TestSecureLoadInc* there obviously is
an {{add}} after a {{set}}. The code in v5 handles that as well as the case
where {{set}} is called after an {{add}}. The unit tests define the semantics
to be that of a standard hierarchically scoped symbol table as described in the
class's javadoc. Let me refer to this, again:
{code}
* For clarity: the shallow merge allows the user to mutate either of the
* configuration objects and have changes reflected everywhere. In contrast to a
* deep merge, that requires you to explicitly know all applicable copies to
* propagate changes.
{code}
bq. In your example above, I think the correct way of overriding key with value
after the add(hri) call is made should be using another add() call. This is
because the order of adding hbase, htd and hri to the compound is significant.
When htd and hri contain entries with same key but different values, I do not
expect htd.set(key, newValue) would be effective.
I noted that the {{Map<...> map}} I've added after the set doesn't have any
overlapping keys. Thus if I set hbasekey using the hbase conf, it should by
the javadoc propagate up to the compoind's get call. The unit tests I added to
the code show this. If I were to add another {{set("hbasekey",..)}} at the htd
level, the htd's hbasekey value would be returned, overriding the hbase level.
*Please be explicit -- provide an example in psuedo-code instead of vague
prose. I don't have the time to infer or to make your own arguments for you.*
If the tests comeback clean, I intend in committing this this afternoon.
> Provide mutability to CompoundConfiguration
> -------------------------------------------
>
> Key: HBASE-8372
> URL: https://issues.apache.org/jira/browse/HBASE-8372
> Project: HBase
> Issue Type: New Feature
> Reporter: Ted Yu
> Assignee: Jonathan Hsieh
> Attachments: hbase-8372.patch, hbase-8372.v2.patch,
> hbase-8372.v3.patch, hbase-8372.v4.patch, hbase-8372.v5.patch
>
>
> In discussion of HBASE-8347, it was proposed that CompoundConfiguration
> should support mutability.
> This can be done by consolidating ImmutableConfigMap's on first modification
> to CompoundConfiguration.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
