ctubbsii commented on issue #1837: URL: https://github.com/apache/accumulo/issues/1837#issuecomment-744710236
> I keep getting told what the code does and I'm trying to propose what it _could_ do. Sorry about that! I understand now. > If in 2.0+ the system-level operations no longer have access to the table contexts, then perhaps this point is moot. In 2.0+, these kinds of operations can still access per-table config, if they need it. Even if we didn't provide an API through the pluggable interface, like we do for the balancer right now, they could always use some other tactic (like reflection or accessing static APIs) to get what they want. So, I don't see that going away any time soon. > Having a table-name-specific-system-level property blurs that structure in a way that I thought it was worth exploring a refactor. I'm not sure if this would be worth it. In general, I've become frustrated with the restrictions of our "we establish the schema, you take what you get" model of configuration property naming. It leads to pluggable implementations that ship with Accumulo using `general.custom.*` and `table.custom.*`, and implementations that could be modularized and separated from our main code base using their own dedicated property keys listed in `Property.java` to the point where they are too tightly coupled with other Accumulo code. It prevents a company at, say "Example, Inc." from using the property namespace `com.example.awesomeiterator.feature1=enabled`, and forces too verbose property names for ones we maintain ourselves. Rather than create a new dedicated namespace for table configuration properties for use in the system namespace, I'd rather relax the restrictions on property names. Then, we could do something like `hostregexbalancer.regex.table1=...` and not be so controlling of how properties are set and managed. We can reserve the `accumulo.*` namespace for ourselves, of course (and the current namespaces, `system.*`, `general.*`, `table.*`, etc. for backwards-compatibility), but otherwise, I don't think we should be too restrictive about properties users set, whether they are in system config or per-table config. ---------------------------------------------------------------- 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]
