[
https://issues.apache.org/jira/browse/IGNITE-14645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14645:
-----------------------------------
Description:
NOTE: description might not be finished.
h3. Problem
Currently configuration schema structure is very restricted and doesn't allow
any variations in it. This approach comes with a set of problems.
# How do you properly configure {{IpFinder}}? For each type of finder you only
need a few properties.
# How do you configure SQL indexes? Pretty much the same problem.
h3. Interface
For the solution we need to expand abilities of configuration schemas. I
propose the following option:
{code:java}
// Configuration schema that contains polymorphic field.
@Config
class TableConfigurationSchema {
@NamedConfigValue
public IndexConfigurationSchema indexes;
}
// Base class for polymorphic value. Explicitly has all subclasses
// in its description to simplify incremental code generation.
@PolymorphicConfig(impl = {
HashIndexConfigurationSchema.class,
TreeIndexConfigurationSchema.class,
})
class IndexConfigurationSchema {
// This annotation shows that current field defines implementation.
// Specific values are present in implementations declarations.
@Id
@Immutable
@Value
public String type;
}
// One of implementations for index. Id value is defined in annotation.
@PolymorphicInstance(id = "hash")
public static class HashIndexConfigurationSchema extends
IndexConfigurationSchema {
@Immutable
@Value
public String column;
}
// Other implementation for index.
@PolymorphicInstance(id = "tree")
public static class TreeIndexConfigurationSchema extends
IndexConfigurationSchema {
@Immutable
@Value
public String[] columns;
}
{code}
h3. Generated API
We need to tweak API a little bit. I'd love to see as few changes as possible,
so my vision is something like this:
{code:java}
TableConfiguration tableCfg = ...;
tableCfg.indexes().create("hashIndexName", index ->
// Id sets up automatically by the call.
index.asHashIndex().changeColumn("columnName")
).get();
tableCfg.indexes().update("hashIndexName", index ->
// Any cast is allowed to do in change request.
// But this update will fail during processing.
index.asTreeIndex().changeColumns("a", "b")
);
IndexConfiguration indexCfg = tableCfg.indexes().get("hashIndexName");
// This must be an instance of "HashIndexConfiguration".
HashIndexConfiguration hashCfg = (HashIndexConfiguration)indexCfg;
// This must be instance of HashIndexView,
IndexView indexView = indexCfg.value();
// Maybe this is redundant, I don't know.
assert indexView.isHashIndex();
// Returns the same object with a safe cast.
// Maybe this is redundant as well and regular cast would be enough.
HashIndexView hashView = indexView.asHashIndex();{code}
h3. Implementation Notes
TODO
was:
NOTE: description might not be finished.
h3. Problem
Currently configuration schema structure is very restricted and doesn't allow
any variations in it. This approach comes with a set of problems.
# How do you properly configure {{IpFinder}}? For each type of finder you only
need a few properties.
# How do you configure SQL indexes? Pretty much the same problem.
h3. Interface
For the solution we need to expand abilities of configuration schemas. I
propose the following option:
{code:java}
// Configuration schema that contains polymorphic field.
@Config
class TableConfigurationSchema {
@NamedConfigValue
public IndexConfigurationSchema indexes;
}
// Base class for polymorphic value. Explicitly has all subclasses
// in its description to simplify incremental code generation.
@PolymorphicConfig(impl = {
HashIndexConfigurationSchema.class,
TreeIndexConfigurationSchema.class,
})
class IndexConfigurationSchema {
// This annotation shows that current field defines implementation.
// Specific values are present in implementations declarations.
@Id
@Immutable
@Value
public String type;
}
// One of implementations for index. Id value is defined in annotation.
@PolymorphicInstance(id = "hash")
public static class HashIndexConfigurationSchema extends
IndexConfigurationSchema {
@Immutable
@Value
public String column;
}
// Other implementation for index.
@PolymorphicInstance(id = "tree")
public static class TreeIndexConfigurationSchema extends
IndexConfigurationSchema {
@Immutable
@Value
public String[] columns;
}
{code}
h3. Generated API
We need to tweak API a little bit. I'd love to see as few changes as possible,
so my vision is something like this:
{code:java}
TableConfiguration tableCfg = ...;
tableCfg.indexes().create("hashIndexName", index ->
// Id sets up automatically by the call.
index.asHashIndex().changeColumn("columnName")
).get();
tableCfg.indexes().update("hashIndexName", index ->
// Any cast is allowed to do in change request.
// But this update will fail during processing.
index.asTreeIndex().changeColumns(new String[] {"a", "b"})
);
IndexConfiguration indexCfg = tableCfg.indexes().get("hashIndexName");
// This must be an instance of "HashIndexConfiguration".
HashIndexConfiguration hashCfg = (HashIndexConfiguration)indexCfg;
// This must be instance of HashIndexView,
IndexView indexView = indexCfg.value();
// Maybe this is redundant, I don't know.
assert indexView.isHashIndex();
// Returns the same object with a safe cast.
// Maybe this is redundant as well and regular cast would be enough.
HashIndexView hashView = indexView.asHashIndex();{code}
h3. Implementation Notes
TODO
> Support polymorphic configuration nodes.
> ----------------------------------------
>
> Key: IGNITE-14645
> URL: https://issues.apache.org/jira/browse/IGNITE-14645
> Project: Ignite
> Issue Type: Sub-task
> Reporter: Ivan Bessonov
> Assignee: Ivan Bessonov
> Priority: Major
>
> NOTE: description might not be finished.
> h3. Problem
> Currently configuration schema structure is very restricted and doesn't allow
> any variations in it. This approach comes with a set of problems.
> # How do you properly configure {{IpFinder}}? For each type of finder you
> only need a few properties.
> # How do you configure SQL indexes? Pretty much the same problem.
> h3. Interface
> For the solution we need to expand abilities of configuration schemas. I
> propose the following option:
> {code:java}
> // Configuration schema that contains polymorphic field.
> @Config
> class TableConfigurationSchema {
> @NamedConfigValue
> public IndexConfigurationSchema indexes;
> }
> // Base class for polymorphic value. Explicitly has all subclasses
> // in its description to simplify incremental code generation.
> @PolymorphicConfig(impl = {
> HashIndexConfigurationSchema.class,
> TreeIndexConfigurationSchema.class,
> })
> class IndexConfigurationSchema {
> // This annotation shows that current field defines implementation.
> // Specific values are present in implementations declarations.
> @Id
> @Immutable
> @Value
> public String type;
> }
> // One of implementations for index. Id value is defined in annotation.
> @PolymorphicInstance(id = "hash")
> public static class HashIndexConfigurationSchema extends
> IndexConfigurationSchema {
> @Immutable
> @Value
> public String column;
> }
> // Other implementation for index.
> @PolymorphicInstance(id = "tree")
> public static class TreeIndexConfigurationSchema extends
> IndexConfigurationSchema {
> @Immutable
> @Value
> public String[] columns;
> }
> {code}
> h3. Generated API
> We need to tweak API a little bit. I'd love to see as few changes as
> possible, so my vision is something like this:
> {code:java}
> TableConfiguration tableCfg = ...;
> tableCfg.indexes().create("hashIndexName", index ->
> // Id sets up automatically by the call.
> index.asHashIndex().changeColumn("columnName")
> ).get();
> tableCfg.indexes().update("hashIndexName", index ->
> // Any cast is allowed to do in change request.
> // But this update will fail during processing.
> index.asTreeIndex().changeColumns("a", "b")
> );
> IndexConfiguration indexCfg = tableCfg.indexes().get("hashIndexName");
> // This must be an instance of "HashIndexConfiguration".
> HashIndexConfiguration hashCfg = (HashIndexConfiguration)indexCfg;
> // This must be instance of HashIndexView,
> IndexView indexView = indexCfg.value();
> // Maybe this is redundant, I don't know.
> assert indexView.isHashIndex();
> // Returns the same object with a safe cast.
> // Maybe this is redundant as well and regular cast would be enough.
> HashIndexView hashView = indexView.asHashIndex();{code}
> h3. Implementation Notes
> TODO
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
