[infinispan-dev] Lucene 5 is coming: pitfalls to consider

[Gustavo Fernandes]

> This is mostly a job for Hibernate Search, but in terms of user
> experience it means you have to mark fields for "sortability"
> explicitly; will we need to extend the protobuf schema?
>


Docvalues in theory are not only useful for sorting, but for aggregations
as well,
so the extra flag should not be tied conceptually to "sorting".



>
> Please make sure we'll just have to hook in existing metadata, we
> can't fix this after API freeze.
>
> # Filters
> We did some clever bitset level optimisations to merge multiple Filter
> instances and save memory to cache multiple filter instances, I had to
> drop that code as we don't deal with in-heap structures more but the
> design is about iterating off heap chunks of data,


Unless the directory implementation stores data in the heap itself :)



> and resort on the
> more traditional Lucene stack for filtering.
> I couldn't measure the performance impact yet; it's a significantly
> different approach and while it sounds promising on paper, we'll need
> some help testing this. The Lucene team can generally be trusted to go
> in the better direction, but we'll have to verify if we're using it in
> the best way.
>
> # Analyzers
> It is no longer possible to override the field->analyzer mapping at
> runtime. We did expose this feature as a public API and I found a way
> to still do it, but it comes with a performance price tag.
> We'll soon deprecate this feature; if you can, start making sure
> there's no need for this in Infinispan as at some time in the near
> future we'll have to drop this, with no replacement.
>
> # Index encoding
> As usual the index encoding evolves and the easy solution is to
> rebuild it. Lucene 5 no longer ships with backwards compatible
> de-coders, but these are available as separate dependencies. If you
> feel the need to be able to read existing indexes, we should include
> these.
> (I'm including these as private dependencies in the Hibernate Search
> modules).
>
> Thanks,
> Sanne
> _______________________________________________
> 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/20150728/f367dedd/attachment-0001.html