On Thu, Oct 27, 2016 at 9:40 AM Tristan Tarrant <ttarr...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev >
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev