Hi Andrei, I don't really know why we are imposing this restrictions so I am also interested by the answer.
I would suspect that in some cases we may want to call schema constructors via RMI or reflection (or something similar) which would be more complicated if the parameters are not primitive types/value objects. Best, Stamatis Στις Τρί, 19 Φεβ 2019 στις 7:39 μ.μ., ο/η Andrei Sereda <[email protected]> έγραψε: > 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. >
