jschmidt10 opened a new issue, #3233: URL: https://github.com/apache/accumulo/issues/3233
On our team, we set the `table.classpath.context` at the system-scope to allow all tables to inherit the context without iterating over dozens of tables to set the override. We will update the classpath context with each release of our software. The `createtable --copy-config` command will pull `conn.tableOperations().getProperties(table)` which includes both table-defined and system-defined properties. It will then evaluate `Property.isValidTablePropertyKey()` on all of those and then add a table property if the check returns true. This is a unique case where `table.classpath.context` is in the system scope (not the table-scope) but the the property name is a valid table property key, so we end up with an override that was not actually in the table we copied from. Here's a quick example to reproduce: ``` config -s table.custom.myprop=value1 createtable table1 createtable -cc table1 table2 config -s table.custom.myprop=value2 config -t table1 -f table.custom.myprop # returns value2 from the system-scope config -t table2 -f table.custom.myprop # returns value1 from the table-scope override generated by copy-configs ``` We copy tables heavily for regression testing and have to manually remove some table.* properties that are system-scoped. Would it be reasonable to only pull the table-scoped properties during the --copy-config operation? -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
