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