If you really want to pass in an object, I suggest to pass in a URI string and then the adapter code can use some kind of directory service (e.g. JNDI) to get the object.
But then how do I retrieve that directory service from Schema (hope not a static variable) ? Don’t you couple a schema to a directory now ? Can schema declare how to build itself ? Like Class<SchemaFactory> getFactoryClass ? You would still be able to instantiate schemas on different VM using SchemaFactory (which uses Json primitives). On Thu, Feb 21, 2019 at 7:52 PM Julian Hyde <[email protected]> wrote: > The original motivation for only allowing serializable parameters was to > allow queries to be run in a different JVM than the one in which they were > prepared. (Remember, in enumerable convention, a prepared query is a > generated java class.) > > (By serializable I mean JSON types: primitives, lists and maps. Not > java.io.Serializable.) > > Allowing non-serializable parameters does indeed provide flexibility, but > it makes it too easy to introduce coupling. So, I still think it is a > sensible constraint. > > If you really want to pass in an object, I suggest to pass in a URI string > and then the adapter code can use some kind of directory service (e.g. > JNDI) to get the object. > > Julian > > > > On Feb 21, 2019, at 3:28 PM, Andrei Sereda <[email protected]> wrote: > > > > SchemaFactory > > < > https://calcite.apache.org/apidocs/org/apache/calcite/schema/SchemaFactory.html > > > > already imposes “serializable” objects using the following interface : > > > > Schema create( > > SchemaPlus parentSchema, > > String name, > > Map<String, Object> operand); > > > > operand parameter is taken from configuration which is basically a JSON. > > > > For RMI, serialization cases can we defer creation of Schema to > > SchemaFactory ? > > > > Julian, since you originally commented on PR, do you have an opinion on > the > > matter ? > > > > On Wed, Feb 20, 2019 at 3:20 AM Stamatis Zampetakis <[email protected]> > > wrote: > > > >> 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. > >>> > >> > >
