Hello, I’m reviewing PR-1036 <https://github.com/apache/calcite/pull/1036> which allows geode schema factory to lookup geode connections from JNDI. An alternative (or perhaps complimentary) approach is to provide GemFireCache as constructor parameter to GeodeSchema directly. The later is used in ElasticsearchSchema <https://github.com/apache/calcite/blob/master/elasticsearch/src/main/java/org/apache/calcite/adapter/elasticsearch/ElasticsearchSchema.java#L68> (see RestClient dependency).
In CALCITE-2443 <https://issues.apache.org/jira/browse/CALCITE-2443> Julian mentioned that schema constructors should accept only “primitive types”: We generally don’t pass objects that are not value objects (think: JSON) to schema constructors. If you need richer objects inside the schema maybe pass a URI then get the real object inside the schema using s JNDI directory service. Or something. Personally, I think that providing dependencies (eg. session / connection / client etc.) in Schema public constructors (or builders) makes them more flexible (think embedded calcite). Is there any reason not to allow schemas to access dependencies directly (either via constructor / builder or schema factory) in public API ? Many thanks, Andrei.
