<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Oct 27, 2016 at 9:40 AM Tristan Tarrant <<a href="mailto:ttarrant@redhat.com">ttarrant@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 27/10/16 00:06, William Burns wrote:<br class="gmail_msg">
> The reason it is a subelement instead of a property is because off-heap<br class="gmail_msg">
> will most likely require some additional configuration to tell how many<br class="gmail_msg">
> entries to store in the a bucket (think non resizing HashMap).<br class="gmail_msg">
<br class="gmail_msg">
Aside from that, it is best to use elements when possible over<br class="gmail_msg">
attributes, as XSD allows more control over constraints and exclusivity.<br class="gmail_msg">
<br class="gmail_msg">
> With these changes storeAsBinary becomes redundant, so I was planning on<br class="gmail_msg">
> removing this configuration completely. I would rather remove since<br class="gmail_msg">
> this is 9.0 and not deprecate. As far as I know nobody really used it<br class="gmail_msg">
> before.<br class="gmail_msg">
<br class="gmail_msg">
While this can be easily removed from the parser, since it supports<br class="gmail_msg">
versioning, I'm not sure I'd want to see it go away from the API. We<br class="gmail_msg">
haven't been very good at doing this in the past and I'd rather go down<br class="gmail_msg">
the conservative route.<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> Also another side effect is I was removing all of the Equivalence<br class="gmail_msg">
> classes. I am not sure if I can plainly remove them since they have<br class="gmail_msg">
> lived in commons for quite a while, but it would be best if I could,<br class="gmail_msg">
> although I am fine deprecating. In its place the instance setting for<br class="gmail_msg">
> data-container will always wrap byte[] to satisfy equals and hashCode<br class="gmail_msg">
> methods.<br class="gmail_msg">
<br class="gmail_msg">
Equivalence is only really used in the context of compatibility mode and<br class="gmail_msg">
that has uses (hybrid servers). How would that continue working (until<br class="gmail_msg">
we get transcoding) ?<br class="gmail_msg"></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
Tristan<br class="gmail_msg">
--<br class="gmail_msg">
Tristan Tarrant<br class="gmail_msg">
Infinispan Lead<br class="gmail_msg">
JBoss, a division of Red Hat<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
infinispan-dev mailing list<br class="gmail_msg">
<a href="mailto:infinispan-dev@lists.jboss.org" class="gmail_msg" target="_blank">infinispan-dev@lists.jboss.org</a><br class="gmail_msg">
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br class="gmail_msg">
</blockquote></div></div>