[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:29 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 templates 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/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?

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