[ 
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirill Tkalenko updated IGNITE-17199:
-------------------------------------
    Description: 
*Problem*
Consider an example of generating configuration interfaces (**Configuration*) 
for an abstract configuration.

Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
    @Value
    public int size;
}

@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
    @Value
    public double evictionThreshold;
}
{code}


Configuration interfaces:
{code:java}
public interface BaseConfiguration<VIEWT extends BaseView, CHANGET extends 
BaseChange> extends ConfigurationTree<VIEWT, CHANGET> {
    ConfigurationValue<Integer> size();
}

public interface VolatileConfiguration extends BaseConfiguration<VolatileView, 
VolatileChange> {
    ConfigurationValue<Integer> size();
}
{code}

This implementation allows us to work with the inheritors of the abstract 
configuration as with a regular configuration (as if 
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but 
when working with the abstract configuration itself, it creates inconvenience. 

For example, to get a view of the abstract configuration, we will need to write 
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration<?, ?> baseConfig1 = ...;
        
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}

Which is not convenient and I would like us to be able to work in the same way 
as with the *VolatileConfiguration*.

*Possible implementations*
* Simplest is to leave it as is;
* Creates an additional configuration interface that will be similar to 
*BaseConfiguration*, for example *BaseConfigurationTree*, but it will be 
extended by *BaseConfiguration* and all its inheritors like 
*VolatileConfiguration*, then there may be confusion about whether to use 
*BaseConfiguration* or *BaseConfigurationTree* in the end, so we need to decide 
how to create a name for such an interface;
** *BaseConfigurationTree*;
** *AbstractBaseConfigurationTree*;
** other.

  was:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*) 
for an abstract configuration.

Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
    @Value
    public int size;
}

@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
    @Value
    public double evictionThreshold;
}
{code}


Configuration interfaces:
{code:java}
public interface BaseConfiguration<VIEWT extends BaseView, CHANGET extends 
BaseChange> extends ConfigurationTree<VIEWT, CHANGET> {
    ConfigurationValue<Integer> size();
}

public interface VolatileConfiguration extends BaseConfiguration<VolatileView, 
VolatileChange> {
    ConfigurationValue<Integer> size();
}
{code}

This implementation allows us to work with the inheritors of the abstract 
configuration as with a regular configuration (as if 
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but 
when working with the abstract configuration itself, it creates inconvenience. 

For example, to get a view of the abstract configuration, we will need to write 
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration<?, ?> baseConfig1 = ...;
        
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}

Which is not convenient and I would like us to be able to work in the same way 
as with the *VolatileConfiguration*.


> Improve the usability of the abstract configuration interface
> -------------------------------------------------------------
>
>                 Key: IGNITE-17199
>                 URL: https://issues.apache.org/jira/browse/IGNITE-17199
>             Project: Ignite
>          Issue Type: Improvement
>            Reporter: Kirill Tkalenko
>            Assignee: Kirill Tkalenko
>            Priority: Major
>              Labels: iep-55, ignite-3
>             Fix For: 3.0.0-alpha6
>
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*) 
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
>     @Value
>     public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
>     @Value
>     public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration<VIEWT extends BaseView, CHANGET extends 
> BaseChange> extends ConfigurationTree<VIEWT, CHANGET> {
>     ConfigurationValue<Integer> size();
> }
> public interface VolatileConfiguration extends 
> BaseConfiguration<VolatileView, VolatileChange> {
>     ConfigurationValue<Integer> size();
> }
> {code}
> This implementation allows us to work with the inheritors of the abstract 
> configuration as with a regular configuration (as if 
> *VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but 
> when working with the abstract configuration itself, it creates 
> inconvenience. 
> For example, to get a view of the abstract configuration, we will need to 
> write the following code:
> {code:java}
> BaseConfiguration baseConfig0 = ...;
> BaseConfiguration<?, ?> baseConfig1 = ...;
>         
> BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
> BaseView baseView1 = baseConfig1.value();
> {code}
> Which is not convenient and I would like us to be able to work in the same 
> way as with the *VolatileConfiguration*.
> *Possible implementations*
> * Simplest is to leave it as is;
> * Creates an additional configuration interface that will be similar to 
> *BaseConfiguration*, for example *BaseConfigurationTree*, but it will be 
> extended by *BaseConfiguration* and all its inheritors like 
> *VolatileConfiguration*, then there may be confusion about whether to use 
> *BaseConfiguration* or *BaseConfigurationTree* in the end, so we need to 
> decide how to create a name for such an interface;
> ** *BaseConfigurationTree*;
> ** *AbstractBaseConfigurationTree*;
> ** other.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

Reply via email to