hlgp commented on issue #1837:
URL: https://github.com/apache/accumulo/issues/1837#issuecomment-744701501
"It sounds like what you're saying is that if table2 sets
table.custom.table1.key = v2, then operations performing in the context of
table1 will see the v2 value instead of v0 or v1. Is that what you are saying?"
-- No, I was not talking about operations within the context of table1. I
was talking about system-level operations, as exhibited by the
HostRegexTabletLoadBalancer which you characterize perfectly here. Everything
hereafter in your synopsis I agree with. We are saying the same things. The
fix is great for this specific issue, but I was thinking bigger picture
thereafter. I keep getting told what the code does and I'm trying to propose
what it *could* do.
What I was saying further was that the behavior of the
HostRegexTabletLoadBalancer brought into question the need for system-level
tablename properties (config.foo.bar.table1) since it does (or did at the time)
pull from all contexts and could have surmised, from each table's context, that
tables own regex. Accumulo has a very nice config inheritance structure:
system-level configs inherited or overridden within each table context as
necessary. Having a table-name-specific-system-level property blurs that
structure in a way that I thought it was worth exploring a refactor. If in
2.0+ the system-level operations no longer have access to the table contexts,
then perhaps this point is moot. If not, it was worth opening up discussions
for a streamlining redesign to keep all table-specific overrides solely within
that tables context.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
