You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@accumulo.apache.org by "jschmidt10 (via GitHub)" <gi...@apache.org> on 2023/03/10 17:15:09 UTC
[GitHub] [accumulo] jschmidt10 opened a new issue, #3233: Only use table-scoped properties when creating table with --copy-config
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: notifications-unsubscribe@accumulo.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] jschmidt10 commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "jschmidt10 (via GitHub)" <gi...@apache.org>.
jschmidt10 commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1464126538
Thanks Ed! Tried it out in 2.1 and got the same behavior. I was unaware of the new opts, so thanks for the heads up. In this case, I was looking for like a "table-scope only copy-configs" but didn't see anything pop out at me.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ivakegg commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ivakegg (via GitHub)" <gi...@apache.org>.
ivakegg commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1602548778
We use the shell to do a lot of operations. This bit us yet again today where we started getting spammed with error messages because of a null pointer exception when trying to create the compaction dispatcher. The root cause was that the SimplyCompactionDispatcher could not be found in the classloader context that had been deleted but yet a cloned table was still pointing to it. Please up the priority of working what I strongly consider to be a bug.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1464120437
Which version of Accumulo are you using?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1615281410
While clone table was mention, it was also mentioned that the -cc option was causing the issue:
```
Table SRCTABLE is cloned to DESTTABLE using -cc, which adds a table level setting for the above property ```
```
as far as I can tell, clonetable does not have a -cc option. createtable and createnamespace do.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1489342730
> Thanks @ctubbsii. Do you have an idea what you'd like the API to look like? Would it be a new flag on the `createtable` command?
Since the shell is using only public API for this (and it shouldn't use internal APIs), we would need to create a new option for NewTableConfiguration to do this internally, rather than only inside the shell. Or, we would first need to create new getters for the shell to be able to retrieve the actual configuration and distinguish that from the effective configuration.
But, I wonder if we really want to do that. It would be exposing a lot of the internals for how we manage configuration, and I'm not sure we really want to do that, because it might be harder to make improvements to that if we lock ourselves in with public API exposures for it.
Another way to think about it is that this flag is really just adding one possible convenience option for users. We're not making any guarantees that it will satisfy everybody's use case... nor is it feasible to add a new flag for convenience for every situation. If the user has a more complex situation than our convenience flags can support, I don't think it would be unreasonable to suggest that they just do their own thing inside their own Java client code, whether that's in JShell or a compiled class. If it becomes a high-demand use case, we could consider adding an additional convenience flag later.
In this case, the situation is happening because of a lot of table properties being set at the system level, and then subsequently trying to create tables with configuration copied from another table. I'm not sure it's a high-demand use case to do that, and probably doesn't warrant the addition of a new flag. I think it would probably make much more sense to save a NewTableConfiguration, set up with the table properties you want, and then to use that as a template for creating new tables, rather than copying existing tables' configurations.
You could also compare your table configuration with the system configuration, to see which items are being overridden, and create a NewTableConfiguration consisting of only those differences.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1464123350
The update properties changed with 2.1 - not sure if the new methods would match your use-case, but there are more options now, starting with 2.1.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1615286205
> While clone table was mention, it was also mentioned that the -cc option was causing the issue:
>
> ```
> Table SRCTABLE is cloned to DESTTABLE using -cc, which adds a table level setting for the above property ```
> ```
>
> as far as I can tell, clonetable does not have a -cc option. createtable and createnamespace do.
Right, it doesn't. That's why I think it's a bug. Whereas the `-cc, --copy-config` option has the semantics of "use the effective config of this other table as a template", the `clonetable` command has the semantics of `make this table behave like the other one, but with a new name`. So, it should copy over the *actual* config, not the effective config... because that wouldn't be the same.
Basically, I think the issue reported here is a mismatch between the user's use case and the actual behavior (the option isn't well-suited for their use case) for the `createtable` command with the `--copy-config` option (something that is being addressed in #3562). But, when it comes to `clonetable` (without any copying options), the same observed problem would be an actual bug, because it's not cloning properly.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] alerman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "alerman (via GitHub)" <gi...@apache.org>.
alerman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1604257963
@ctubbsii The Table configuration was not bad, when the table was cloned. Here is the steps that cause this for us:
1. System wide context is set to CONTEXTA (in 1.10 with table.classpath.context, in 2.1.0 with table.class.loader.context) -- This is _not_ set on the table itself
2. Table SRCTABLE is cloned to DESTTABLE using `-cc`, which adds a table level setting for the above property
3. CONTEXTB is added, and the property is updated (in 1.10 with table.classpath.context, in 2.1.0 with table.class.loader.context)
4. After some time, CONTEXTA is deleted
5. DESTTABLE now throws errors because CONTEXTA is gone
As the user, i have no idea that there is a table level property unless I go check. This isnt expected. SRCTABLE did not have a table level context set, so why does DESTTABLE. This didn't just copy the config, it added new table level properties which were not set on SRCTABLE when the create with copy config was run
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1615276055
@ivakegg Mentioned a cloned table earlier. I checked, and it doesn't look like we even have a `--copy-config` option for the clone table command. It looks like we might automatically infer it, though... and then we provide a mechanism to set additional options, and exclude others, when you clone the table. If clone table is copying the effective config, and not the actual config, then that's not just a break in user expectations like it is for the `--copy-config` option on `createtable` command. That's an actual bug in the clone table command. Cloning a table should always copy the actual config, not the effective config.
So, the work on #3562 to address this for `createtable` is only part of a solution. `clonetable` still needs to be fixed, if that's doing what Ivan implied its doing above, when he referred to a cloned table. (It's possible clone table is fine, though, and he was just referring to a clone of a table that was first created using `createtable --copy-config`, but this needs to be investigated before we can close out this issue.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1604955414
@alerman Thanks for the clarification. I misunderstood @ivakegg 's explanation, and thought the clone table's config was being copied. I now understand that the problem was in the cloned table itself, not a table created using it as a template.
@ddanielr One quirk about the shell's `config` command is that you can't see overrides at all, unless they differ from the parent, because there is no public API to see only the properties set on a table, but ignoring stuff coming from underneath. So, the shell can only see these overrides after the system property has changed.
But yes, we absolutely could provide a flag, and a new public API to view the overrides, or view only the specific scoped properties, without showing the effective properties from the entire hierarchy, and we could also add a new `-cc`-like flag that only uses those properties as a template, instead of the effective properties.
***
However, there's a much simpler solution that is immediately available to the users impacted by the current behavior: just don't use the per-table property to specify the context the way you're doing it. Instead, use a custom property name that holds the URLs (or other context) that isn't a per-table property that gets copied, and use the table parameter as a context group reference that doesn't change. This merely takes a small bit of imagination to implement.
For example:
```java
public class MyCustomClassLoaderContextFactory implements ContextClassLoaderFactory {
private ContextClassLoaderEnvironment env;
@Override
public void init(ContextClassLoaderEnvironment env) {
this.env = env;
}
@Override
public ClassLoader getClassLoader(String contextGroup) {
// interpret context parameter as a "context group", but read current URLs from a different location
String urls = env.getConfiguration().get("general.custom.myclassloader.group." + contextGroup);
// ... create new URLClassLoader from urls and return that
}
}
```
So now, instead of changing the per-table property at the system level, you change this other property that is the actual context for that contextGroup by editing `general.custom.myclassloader.group.somegroupname` and `table.class.loader.context` just stays fixed at `somegroupname` and is set only on the table, not at the system (but even if it's set at the system, it's not a problem, if it's never changed).
This is actually way more powerful than what you are currently doing, because you can still get different classloaders for different groups of tables, whereas the way you're currently using the table property at the system config, your factory would necessarily give the same classloader to every table in the system.
In my example, the context you're changing is a set of URLs, but it could be something else, depending on your factory implementation. It could even be another redirect to a named URL set, if you want to stage different named URL sets in your config, and then just swap them out by name in your factory.
This is the power of the pluggable factory interface that we made, and one of the reasons we designed it this way... you are no longer bound to the limitations of our previous ways of doing per-table classloader contexts... you can use these contexts as indirect jumps to your mutable contexts. Your contexts on your tables can represent anything you wish.
***
So, yes, we can add the API updates and flags to the shell command... but even if we didn't, you don't need to let this limitation affect you. You just need to use the new context and factory SPI a bit more effectively.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ddanielr commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ddanielr (via GitHub)" <gi...@apache.org>.
ddanielr commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1604319936
TL;DR Would adding a `overrides only` flag for the table clone config (`-cc`) command work as a solution?
@alerman I made a visual based off your steps.
Original State:
| Tables | Table Property | System Properties |
| ------------- | ------------- | ------------- |
| SRCTABLE | N/A | table.class.loader.context=CONTEXT-A |
After Table Clone using `-cc`:
| Tables | Table Properties | System Properties |
| ------------- | ------------- | ------------- |
| SRCTABLE | N/A | table.class.loader.context=CONTEXT-A |
| DESTTABLE | table.class.loader.context=CONTEXT-A | table.class.loader.context=CONTEXT-A |
A new system context is created (CONTEXT-B) and the old context (CONTEXT-A) is deleted:
| Tables | Table Properties | System Properties |
| ------------- | ------------- | ------------- |
| SRCTABLE | N/A | table.class.loader.context=CONTEXT-B |
| DESTTABLE | table.class.loader.context=CONTEXT-A | table.class.loader.context=CONTEXT-B |
DESTTABLE now throws errors due to the missing CONTEXT-A
Validating the table config is time consuming as it is also a per-table check rather than a per-property check.
The `config -f table.class.loader.context` command doesn't show per-table properties overrides unless a specific table name is also passed
`config -t DESTTABLE -f table.class.loader.context`.
Any table clone operation run would need a comparison of the `@override` results of both table configs.
Given that the overrides are probably the only desired parts of the table config in this scenario, is it possible to just selectively copy those out to the clone table?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] keith-turner commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "keith-turner (via GitHub)" <gi...@apache.org>.
keith-turner commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1495225215
The new 2.1.0 API [TableOperations.getTableProperties()](https://github.com/apache/accumulo/blob/1409bc0fdd8fa9b262d8de5a388af99ef5deb61e/core/src/main/java/org/apache/accumulo/core/client/admin/TableOperations.java#L513-L526) may facilitate this along with a new options on the shell command. That new API only returns the props set on a table. Could add a new option like --copy-only-table-config that uses TableOperations.getTableProperties()
Looking at the current create table command I was surprised that it creates the table and set then copies the config. It would be better if it used [NewTableConfiguration.setProperties()] (https://github.com/apache/accumulo/blob/1409bc0fdd8fa9b262d8de5a388af99ef5deb61e/core/src/main/java/org/apache/accumulo/core/client/admin/NewTableConfiguration.java#L143) to set the props prior to creation.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1464129875
The new changes are not related to copy config - but there are now ways to atomically set / modify a group of properties - seemed similar enough to mention, but again, not sure if they fit what this is asking for,
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1464359156
The issue here is basically whether copy config should copy the actual config or the effective config. It currently copies the effective config, since there's no good way to view the actual config. In 2.1, with the way we've changed how properties work, it might be easier to resolve just the actual config and bypass the effective config... but I think if we change that behavior, it should be done with a new API, rather than break the existing API.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman closed issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman closed issue #3233: Only use table-scoped properties when creating table with --copy-config
URL: https://github.com/apache/accumulo/issues/3233
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ivakegg commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ivakegg (via GitHub)" <gi...@apache.org>.
ivakegg commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1623877049
I will have to apologize as the clonetable command is doing the correct thing for us. I was fooled when doing the upgrade from 1.10.2 to 2.1.1 where the table properties at the system level appeared to be copied into the table configurations. I had assumed it was the clonetable command that was the culprit but, thanks to Ed, I have proved this was not the case.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1624182390
I ran a test, upgrading from 1.10 to 2.1 and I don't see the issue with the upgrade process either - details in comment on PR #3562
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] jschmidt10 commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "jschmidt10 (via GitHub)" <gi...@apache.org>.
jschmidt10 commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1488601928
Thanks @ctubbsii. Do you have an idea what you'd like the API to look like? Would it be a new flag on the `createtable` command?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] jschmidt10 commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "jschmidt10 (via GitHub)" <gi...@apache.org>.
jschmidt10 commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1464120812
This was found on 1.10.2
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1603621716
@ivakegg It's not clear to me how changing the behavior of `createtable -cc` would have prevented the errors you described in your last comment. If the cloned table had a bad/out-of-date config, then copying it to a new table using `createtable -cc clonedTable newTable` would have copied over the bad configuration from the cloned table, in both the current behavior and the desired behavior, because the bad config was on the table's config itself and not inherited. If I'm mistaken on this, can you please elaborate as to where the config was stored, and what your desired behavior was?
> Please up the priority of working what I strongly consider to be a bug.
I will grant that there is a mismatch between the behavior of this flag and user expectations in some cases, and that the current behavior may make it unsuitable for certain use cases (such as the one described), but it's not a bug. It is still working as intended, copying over the effective table configuration.
We can try to support your use case better by adding new features for you, but the current code is not a bug.
Have you tried, or at least considered trying, the alternative approach using a NewTableConfiguration as a table template, rather than using a pre-existing table? Or subtracting out the configs stored at the system level that you want to inherit after copying from another table?
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ctubbsii commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ctubbsii (via GitHub)" <gi...@apache.org>.
ctubbsii commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1615299585
Okay, nevermind... I just located the part of the code that does the config copy for the clone, and it's literally just copying the config node in ZK from one table to the other. It doesn't do any `TableConfiguration` effective hierarchy when it copies the config over during a clone operation. So, forget I said anything about `clonetable`... it's not a problem. :smiley_cat: Ed's work on #3562 should suffice.
That said, I'm still very much interested in hearing feedback on my suggestion to fix the classloader factory that I made in https://github.com/apache/accumulo/issues/3233#issuecomment-1604955414
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] EdColeman commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "EdColeman (via GitHub)" <gi...@apache.org>.
EdColeman commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1642452805
Fixed with PR #3562. Adds --exclude-parent as an option to the --copy-config option in createtable and createnamespace.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [accumulo] ivakegg commented on issue #3233: Only use table-scoped properties when creating table with --copy-config
Posted by "ivakegg (via GitHub)" <gi...@apache.org>.
ivakegg commented on issue #3233:
URL: https://github.com/apache/accumulo/issues/3233#issuecomment-1623847387
OK, I have created a ton of confusion for everybody. This same "copy properties" vs "copy config" needs to also be extended to the clonetable command. I previously thought this was one in the same code path but obviously not.
--
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: notifications-unsubscribe@accumulo.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org