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

[Tristan Tarrant]

I'll take care of that. Our blog queue is quite long and I don't want to 
put out everything at once.

Rate limiting mode: on.

Tristan


On 11/09/2015 16:34, Sanne Grinovero wrote:
> +1 for someone to do that :)
> Sorry I can't volunteer, this is my last day before going for holidays
> next two weeks.. see you all in Rome.
>
> What I wrote here was mostly targeting Infinispan developers and
> integrators; ony the @SortableField is relevant to end users too: feel
> free to advertise our post on the matter, but it's not written yet!
> Next week.
>
> The Infinispan team should start thinking of exposing the equivalent
> of @SortableField for Hot Rod, in preparation for when we'll kill the
> old strategy (we might need to). I guess it would be more interesting
> to Infinispan users when you actually have that alternative to migrate
> to.
>
> Cheers,
> Sanne
>
>
> On 11 September 2015 at 15:21, Galder Zamarreno <galder at redhat.com> wrote:
>> Any chance of cross-posting the info/post to the Infinispan blog?
>>
>> Cheers,
>> --
>> Galder Zamarreño
>> Infinispan, Red Hat
>>
>> ----- Original Message -----
>>> A wrap up on this subject.
>>>
>>> Infinispan 8 is now based on Lucene 5.3 and all problems I previously
>>> listed are dealt with in a mostly-backwards compatible way; this is
>>> what you need to know.
>>>
>>> ## Null Markers
>>> One exception is null-marker tokens: when applied to a NumericField
>>> they now shall be represented by a number of the matching type of the
>>> field.. no big deal.
>>>
>>> ## Sorting
>>> The bigger issue was sorting, and its need for appropriate metadata,
>>> so that we'd know at indexing time which fields would potentially be
>>> the target for a sorting query.
>>>
>>> Our solution in Hibernate Search 5.5 is to provide a @SortableField
>>> annotation to allow users (and integrators like Infinispan Remote
>>> Query) to mark fields for this purpose, but also we're falling back to
>>> a slower sorting strategy in case at runtime a Query is run targeting
>>> wich a field which was not appropriately annotated.
>>>
>>> But while you might think "great, I don't have any change to do",
>>> especially if you don't need the extra performance boost that
>>> @SortableField would provide, make sure to start migrating
>>> infrastructure to use this annotation as the fallback strategy won't
>>> be maintained forever!
>>>
>>> With the next version we'll - by default - refuse to use the fallback
>>> and get a runtime exception, but still provide a configuration option
>>> to allow it. That would be a great time to make sure all your needs
>>> are covered by the new alternative metadata. After that we will get
>>> rid of the fallback strategy.
>>>
>>> Gunnar is going to publish a blog post with more details next week on
>>> the Hibernate blog: http://in.relation.to/ , please watch that space.
>>>
>>> ## Index encoding
>>> Hibernate Search is including the backwards compatible codecs.
>>> Infinispan could decide to include them too, if you prefer.
>>>
>>> ## Dynamic Analyzer choices
>>> We managed to keep this feature even if Lucene doesn't allow it, we'll
>>> probably deprecate this like with sorting but I guess this doesn't
>>> require any upfront work from Infinispan.
>>>
>>> Thanks,
>>> Sanne
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>>
>>
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat