[infinispan-issues] [JBoss JIRA] (ISPN-4919) Configuration templates

[Paul Ferraro (JIRA)]

    [ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13024483#comment-13024483 ] 

Paul Ferraro edited comment on ISPN-4919 at 12/2/14 11:18 AM:
--------------------------------------------------------------

[~NadirX] I'm not arguing against the concept, just the usability/implementation.  It's not just the schema that implies different behavior, but the Resources themselves.  The cache resource and its children don't have nullable attributes.  Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation.  So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable.

In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache.  You guys changed this in 5.x-7.0, where Configuration objects are now completely defined.  new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration.  Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.

It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior.  Is that a fair summation?


was (Author: pferraro):
[~NadirX] I'm not arguing against the concept, just the usability.  It's not just the schema that implies different behavior, but the Resources themselves.  The cache resource and its children don't have nullable attributes.  Every attribute of a cache and its children (e.g. transaction, locking, etc.) have default values that are applied to the model if no value was specified via a given operation.  So, from the perspective of an add/write-attribute operation, there's no simple way to distinguish a value that is intended to be overridden from one that is intended to be inherited -- /unless/ you create parallel resource definitions for template vs extending caches, where the resource attribute definitions for extending caches are completely nullable.

In general though - the Configuration objects in 4.x did support the concept of overrides - where every property of the cache might be undefined, and thus take a default from some template or default cache.  You guys changed this in 5.x-7.0, where Configuration objects are now completely defined.  new ConfigurationBuilder().read(configuration) is semantically very different than the 4.x behavior, since a new configuration builder is already completely defined, and the read(Configuration) operation is effectively a means for cloning the entire configuration.  Overriding is only every supported via programmatic calls to the resulting configuration builder - which is now a clone of the read configuration.

It sounds like you guys want to revert the current Configuration behavior to be more like the 4.x configuration behavior.  Is that a fair summation?

> Configuration templates
> -----------------------
>
>                 Key: ISPN-4919
>                 URL: https://issues.jboss.org/browse/ISPN-4919
>             Project: Infinispan
>          Issue Type: Feature Request
>          Components: Configuration
>            Reporter: Tristan Tarrant
>            Assignee: Tristan Tarrant
>             Fix For: 7.1.0.Beta1
>
>
> Currently there is a 1:1 relationship between configuration and named caches. While the programmatic API does have the ability to .read() an existing configuration to create a new one, the declarative config does not.
> We should introduce the concept of configuration inheritance, e.g.:
> {code}
> <local-cache name="eviction-cache">
>     <eviction strategy="LIRS" maxEntries="10000"/>
> </local-cache>
> <local-cache name="mycache" template="eviction-cache" />
> {code}
> Possibly, cache templates should be made "abstract" so that they cannot be instantiated as named caches directly, e.g.:
> {code}
> <local-cache name="eviction-cache" abstract="true">
> ...
> </local-cache>
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.8#6338)