lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: [DISCUSS] Change Query API to make queries immutable in 6.0
Date Thu, 02 Apr 2015 13:45:36 GMT
Boosts might not make sense to become immutable, it might make the
code too complex. Who is to say until the other stuff is fixed first.
The downsides might outweight the upsides.

So yeah, if you want to say "if anyone disagrees with what the future
might look like i'm gonna -1 your progress", then i will bite right

Fixing the rest of Query to be immutable, so filter caching isn't
trappy, we should really do that. And we have been doing it already. I
remember Uwe suggested this approach when adding automaton and related
queries a long time ago. It made things simpler and avoided bugs, we
ultimately made as much of it immutable as we could.

Queries have to be well-behaved, they need a good hashcode/equals,
thread safety, good error checking, etc. It is easier to do this when
things are immutable. Someone today can make a patch for FooQuery that
nukes setBar and moves it to a ctor parameter named 'bar' and chances
are a lot of the time, it probably fixes bugs in FooQuery somehow.
Thats just what it is.

Boosts are the 'long tail'. they are simple primitive floating point
values, so susceptible to less problems. The base class incorporates
boosts into equals/hashcode already, which prevents the most common
bugs with them. They are trickier because internal things like
rewrite() might "shuffle them around" in conjunction with clone(), to
do optimizations. They are also only relevant when scores are needed:
so we can prevent nasty filter caching bugs as a step, by making
everything else immutable.

On Thu, Apr 2, 2015 at 9:27 AM,
<> wrote:
> On Thu, Apr 2, 2015 at 3:40 AM, Adrien Grand <> wrote:
>> first make queries immutable up to the boost and then discuss
>> if/how/when we should go fully immutable with a new API to change
>> boosts?
> The “if” part concerns me; I don’t mind it being a separate issue to make
> the changes more manageable (progress not perfection, and all that).  I’m
> all for the whole shebang.  But if others think “no” then…. will it have
> been worthwhile to do this big change and not go all the way?  I think not.
> Does anyone feel the answer is “no” to make boosts immutable? And if so why?
> If nobody comes up with a dissenting opinion to make boosts immutable within
> a couple days then count me as “+1” to your plans, else “-1” pending that
> discussion.
> ~ David Smiley
> Freelance Apache Lucene/Solr Search Consultant/Developer

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message