[infinispan-dev] Data Container configuration changes

[William Burns]

On Thu, Oct 27, 2016 at 9:40 AM Tristan Tarrant <ttarrant at redhat.com> wrote:

> 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20161027/291b5b13/attachment.html