[
https://issues.apache.org/jira/browse/CALCITE-2815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16789839#comment-16789839
]
Andrei Sereda commented on CALCITE-2815:
----------------------------------------
[~julianhyde] Here are my thoughts I'm happy to debate them. Please let me know
your opinion.
If I understand correctly, you want to instantiate Schemas in different VMs. I
think this can be achieved without forcing constructors to accept only “JSON”
(primitive / serializable) objects:
# Re-use current API of
[SchemaFactory|https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/schema/SchemaFactory.java]
which already forces user to provide configuration as {{Map<String, Object>}}
(or JSON object).
# Allow schemas to expose their configuration individually (using common API).
{code:java}
ConfigurableSchema extends Schema {
// also can throw UnsupportedOperationException
Map<String, Object> schemaConfiguration();
Class<? extends SchemaFactory> schemaFactory();
}
{code}
This configuration should be sufficient to instantiate a Schema on a different
VM.
# If above is not an option, perhaps introduce new interface
{{Creator<Schema>}} which will be smart enough to instantiate schema based on
class / configuration and/or other context.
Reasons why I think using registry (JNDI) is not ideal:
# Forcing user to use intermediate layer of abstraction and dependency. He/She
has to remember to register / de-register a JNDI object.
# This becomes more complicated when Schema has more than one dependency (do
we have to register all of them?) or when there are many schemas.
# Can Schema depend on JNDI context itself ? Or should it access a “global
state” (variable) ?
# How to guarantee that JNDI name is unique (user is responsible for naming
without collisions) ?
# API becomes more convoluted.
# It is difficult to test (more state to manage).
# Existing code already uses complex objects.
For example
[CsvSchema|https://github.com/apache/calcite/blob/master/example/csv/src/main/java/org/apache/calcite/adapter/csv/CsvSchema.java#L45]
has a dependency on `java.io.File` (directory). Is it considered a complex
object ? If so, should it be String ? or should it be registered in JNDI ?
Similar thing with
[SplunkSchema|https://github.com/apache/calcite/blob/master/splunk/src/main/java/org/apache/calcite/adapter/splunk/SplunkSchema.java#L40]
> GeodeSchemaFactory change to pass in clientCache using geode jndi context
> -------------------------------------------------------------------------
>
> Key: CALCITE-2815
> URL: https://issues.apache.org/jira/browse/CALCITE-2815
> Project: Calcite
> Issue Type: Improvement
> Components: geode
> Reporter: Sandeep Chada
> Priority: Major
> Labels: pull-request-available
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> We need ability to pass clientCache to GeodeSchemaFactory create static
> function. In our application we already have clientCache pre created.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
