[infinispan-dev] Data Container configuration changes

[Tristan Tarrant]

On 27/10/16 00:06, William Burns wrote:
> The reason it is a subelement instead of a property is because off-heap
> will most likely require some additional configuration to tell how many
> entries to store in the a bucket (think non resizing HashMap).

Aside from that, it is best to use elements when possible over 
attributes, as XSD allows more control over constraints and exclusivity.

> With these changes storeAsBinary becomes redundant, so I was planning on
> removing this configuration completely.  I would rather remove since
> this is 9.0 and not deprecate.  As far as I know nobody really used it
> before.

While this can be easily removed from the parser, since it supports 
versioning, I'm not sure I'd want to see it go away from the API. We 
haven't been very good at doing this in the past and I'd rather go down 
the conservative route.

> Also another side effect is I was removing all of the Equivalence
> classes.  I am not sure if I can plainly remove them since they have
> lived in commons for quite a while, but it would be best if I could,
> although I am fine deprecating.  In its place the instance setting for
> data-container will always wrap byte[] to satisfy equals and hashCode
> methods.

Equivalence is only really used in the context of compatibility mode and 
that has uses (hybrid servers). How would that continue working (until 
we get transcoding) ?

Tristan
-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat