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

[ https://issues.jboss.org/browse/ISPN-4919?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on ISPN-4919 at 12/2/14 11:17 AM: -------------------------------------------------------------- [~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? 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 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? -- This message was sent by Atlassian JIRA (v6.3.8#6338)