Directory services are usually built-in. And that’s as they should be. There’s nothing stopping you from creating schemas (or trees of schemas) manually. And yes, you can put whatever kinds of objects you like as constructor parameters for your schema. But if you want to use SchemaFactory, or model JSON, or you want your plan to be instantiable in a different context or VM, you have to play by the rules.
> On Feb 21, 2019, at 5:08 PM, Andrei Sereda <[email protected]> wrote: > > 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. >>>>> >>>> >> >>
