vdiravka commented on pull request #2251: URL: https://github.com/apache/drill/pull/2251#issuecomment-882856859
* **Motivation:** The goal is to allow multi-tenant operations. So it doesn't matter what API user uses: REST, JDBC ot ODBC. This is true that Drill initially wasn't designed for that, but we ca add it. * **Options:** > The user has to be able to set the user options. We don't need a new option level. Simply add a new statement: ALTER USER > SET <name>=<value>. This would do two things: > Write the given key/value pair into the persistent store for the user. > Change the session option in the current session to that new value. This is also questionable, because it breaks `SessionOptionManager extends InMemoryOptionManager`: ``` This is an OptionManager that holds options in memory rather than in a persistent store. Options stored in SessionOptionManager, QueryOptionManager, and FragmentOptionManager are held in memory (see options) whereas the SystemOptionManager stores options in a persistent store. ``` Most likely all easy ways here are some sort of hacks. So let's do that in correct manner: adding the new `UserOptionManager` as a layer between `SystemOptionManager` and `SessionOptionManager`. > The next step is store the per-user plugins in separate persistent stores. This is the "cleaner" design, but now you have to > create the means for an admin to see, change, and remove the user-level plugins. You also have to extend the plugin registry, > which is, as we noted, a complex beast. Any change requires extensive unit tests. Different PS can be chosen per Drill doc. This is independent from Plugins. We have `HBasePersistentStore`, `InMemoryStore`, `LocalPersistentStore`, `MongoPersistentStore`, `NoWriteLocalStore`, `ZookeeperPersistentStore` implementations for PS. If you mean different instances of the same`PS`, that is not needed. PSRegistry is just a code, which allows to access actual PS. We can manage access via the common PSRegistry. Or we can reconsider it in future. * **Plugins:** About plugins it makes sense to add Global plugins and to use it in case User plugin is absent. It's like a plugins fallback. And system plugins can be used only in scope of Global plugins. I don't think user name in schema is a nice and elegant solution. I think plugins fallback is simpler and more convenient approach. * **Conclusion:** So I am going to add this functionality to current implementation and separate out `user options` part of this PR into the new one. -- 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]
