<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This is mostly a job for Hibernate Search, but in terms of user<br>
experience it means you have to mark fields for &quot;sortability&quot;<br>
explicitly; will we need to extend the protobuf schema?<br></blockquote><div><br><br></div><div>Docvalues in theory are not only useful for sorting, but for aggregations as well, <br></div><div>so the extra flag should not be tied conceptually to &quot;sorting&quot;.<br><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Please make sure we&#39;ll just have to hook in existing metadata, we<br>
can&#39;t fix this after API freeze.<br>
<br>
# Filters<br>
We did some clever bitset level optimisations to merge multiple Filter<br>
instances and save memory to cache multiple filter instances, I had to<br>
drop that code as we don&#39;t deal with in-heap structures more but the<br>
design is about iterating off heap chunks of data, </blockquote><div><br></div><div>Unless the directory implementation stores data in the heap itself :)<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">and resort on the<br>
more traditional Lucene stack for filtering.<br>
I couldn&#39;t measure the performance impact yet; it&#39;s a significantly<br>
different approach and while it sounds promising on paper, we&#39;ll need<br>
some help testing this. The Lucene team can generally be trusted to go<br>
in the better direction, but we&#39;ll have to verify if we&#39;re using it in<br>
the best way.<br>
<br>
# Analyzers<br>
It is no longer possible to override the field-&gt;analyzer mapping at<br>
runtime. We did expose this feature as a public API and I found a way<br>
to still do it, but it comes with a performance price tag.<br>
We&#39;ll soon deprecate this feature; if you can, start making sure<br>
there&#39;s no need for this in Infinispan as at some time in the near<br>
future we&#39;ll have to drop this, with no replacement.<br>
<br>
# Index encoding<br>
As usual the index encoding evolves and the easy solution is to<br>
rebuild it. Lucene 5 no longer ships with backwards compatible<br>
de-coders, but these are available as separate dependencies. If you<br>
feel the need to be able to read existing indexes, we should include<br>
these.<br>
(I&#39;m including these as private dependencies in the Hibernate Search modules).<br>
<br>
Thanks,<br>
Sanne<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote></div><br></div></div>