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.
Not sure I understand, so you are saying to remove it from the parser/xsd but keep it in the programmatic configuration? And just to clarify the new binary element would replace storeAsBinary.
> 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) ?
Equivalence is only used when you are storing byte[] objects, which Infinispan would support directly with no configuration with the new changes (we would wrap the byte[] to ensure equals/hashCode). Compatibility would work the same way it does right now, I just had to add in some handling for the wrapper in some parts of code.
Tristan
--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
infinispan-dev mailing list
infinispan-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev