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 filter? Thanks a lot. -Selva On Sat, Jun 27, 2015 at 5:33 PM, Adrien Grand <jpou...@gmail.com> 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 > <selva.kumar.at.w...@gmail.com> 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: java-user-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-user-h...@lucene.apache.org > >
