ctubbsii edited a comment on pull request #1968: URL: https://github.com/apache/accumulo/pull/1968#issuecomment-808252030
> But I think by not including encryption as a table characteristic we are pushing more complexity to the user and creating more complexity in the code. Instead of the user configuring the service like they would other table specific classes (balancer, scan dispatcher) they have to know specialized options within the service (they will have to know some, key location etc). Then Accumulo has to deal with special circumstances of having general properties that operate on a per-table basis. How will table operations like clone or export table know how to include encryption as part of the operation? As a user, I would expect a cloned table to also be encrypted. It seems you are creating a lot of complexity just to save a few properties. I think you're right that it makes sense to have some of this as table characteristics. I wasn't arguing against that part of the config. But your point is well-taken, and definitely leads itself to using the `table.crypto.opts.SOMETABLEOPT=SOMEVALUE` suggestion I mentioned above so that the per-table characteristics are stored with the table, rather than in the instance/general configuration opts (except for the WAL-related opts, which are necessarily in instance or general opts). Since I was just looking at the classloader stuff a moment ago, I think I will use that as an analogy: The classloader has a "context" property on a table. This context is a hint to the centrally managed classloader factory service. The clasloader factory is responsible for constructing a classloader, given a context. It can choose to ignore the context and provide the same classloader every time. Or, it can decide to produce a classloader that depends on the context (such as interpreting the context as a class path and returning a corresponding URLClassLoader). The classloader factory is the authority, but takes hints from the per-table characteristic. I think this model works well, and I think it should be applied to the per-table crypto as well. I believe this is similar to how the per-table balancer works as well, as well as the per-table volume chooser. The scan dispatcher is a bit more complicated, but I think it's also similar, in that there is centralized executors in the tserver, and the per-table config (dispatcher) provides information to select an executor. In short: centralized pluggable services, that have per-table config I think is better than having per-table services. -- 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]
