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