lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Selva Kumar <>
Subject Re: Lucene 5: Query and Filter merger
Date Sat, 27 Jun 2015 23:30:41 GMT
Hi Adrien

it appears 4.x Filter and our custom implementation inherited Object's
hashcode and equals method. Obviously, this worked for us so far. Logical
equality might not be important in this case and likely to be expensive
given the nature of the custom filters.

Just wanted to understand any changes are around the corner before I
override these methods in the custom filters.

It seems in some sense Filter has already become a Query. So what does it
mean to rewrite filter using Query API?
Search would call take only query instead of combination of query and

Thanks a lot.

On Sat, Jun 27, 2015 at 5:33 PM, Adrien Grand <> wrote:

> Hi Selva,
> Indeed, this default implementation is not good enough for most
> filters and should be extended in order to include parameters that
> define the "identity" of the filter. One could argue that using object
> identity might be a better default, but since Filter now extends Query
> it also needs to implement clone() in such a way that a clone of a
> filter is equal to the original filter, which would never work when
> using object identity by default for equals.
> If you have custom filters, I would encourage you to rewrite them
> using the query API instead of Filter.
> On Sat, Jun 27, 2015 at 2:38 AM, Selva Kumar
> <> wrote:
> > With Query/Filter merger, it appears default Filter hashcode() varies by
> > class, not object instance. Different object instances could have same
> > value. Am I missing something?
> --
> Adrien
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message