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. >>> >>
