lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andi Vajda <>
Subject Re: Proposal about Version API "relaxation"
Date Tue, 13 Apr 2010 18:17:56 GMT

On Apr 13, 2010, at 11:09, Shai Erera <> wrote:

> > That is a static default!
> Yes Uwe ... I'm aware of that :)
> But that's not a static default for Lucene ... only for the  
> application, if it chooses to use it ...

So you have two apps on the same vm and both choose to use this global  
and pick different values. Now what ?

The static default is for the entire classloader, not just Lucene or  
the app.

Using global statics is flawed.


> > so there are no plans to reimplement such a thing again
> Well ... that's not exactly what I'm proposing here. I'm not for re- 
> implementing any sort of staticness, unless the app chooses to use  
> it. And please don't give me that 'there are no plans ...' answer -  
> it kind of kills the discussion, which is not healthy for a community.
> I agree that static variables might cause troubles to some  
> deployments, BUT:
> 1) Not all apps are deployed on a Web Server together with other  
> apps who happen to use Lucene.
> 2) Those that are deployed on web servers usually include lucene.jar  
> in their classpath and are loaded by a different class loader than  
> the rest ...
> So we're really talking about deployments where Lucene is a common,  
> shared library between all apps ...
> And I guess that what bothers me the most is that it feels to me  
> like we're trying to protect people from stuff we haven't yet  
> received complaints on (at least none that I'm aware of), while  
> we're hurting the programming experience of others ... almost  
> recklessly. I'd hope we can find a way around that, because today I  
> pass the same Version value around everywhere, and it's simply  
> inconvenient. Just yesterday people complained about the need to  
> call writer.commit() after new IW() if they want to open a  
> reader ... one-liner inconvenience vs. dozen of lines here -- point  
> is, what's perceived as unnecessary code DOES bother people ... only  
> here it's just a setting thing, and my proposal is not to make it  
> generically static. So let's not get caught on that 'static-ness'.  
> And besides, if you ask me - variables like Version, that are needed  
> in so many places, are usually made static ... but not in Lucene ...
> So if possible ... I'd like to think how we can fix/improve the use  
> of Version, in ways that won't break apps. Because the fact to the  
> matter is - we invented Version to allow for changes w/o breaking  
> back-compat, while the backwards section in CHANGES seems to grow  
> from release to release (I know - I'm partly to blame for it :)),  
> and another fact is that I don't remember even one complaint about a  
> change which broke back-compat. People have raised this issue  
> numerous times in the past, even proposed all sorts of contracts and  
> definitions on how we can be 'allowed' to break back-compat ... but  
> nothing came out of it.
> The fact that we are not able to reach consensus doesn't mean the  
> problem doesn't bother many out there. And ignoring the fact that  
> currently the API looks cluttered is not doing any good. There must  
> be away to allow some apps out there (IMO the majority) to set that  
> Version thing once, and let Lucene use that value everywhere  
> else ... while for others to pass it along as much as they want.
> Shai
> On Tue, Apr 13, 2010 at 7:41 PM, Uwe Schindler <>  
> wrote:
> Hi Shai,
> one of the problem I have is: That is a static default! We want to  
> get rid of them (and did it mostly, only some relicts remain), so  
> there are no plans to reimplement such a thing again. The badest one  
> is BooleanQuery.maxClauseCount. The same applies to all types of  
> sysprops. As Lucene and solr is mostly running in servlet  
> containers, this type of thing  makes web applications no longer  
> isolated. This is also a general contract for libraries: never ever  
> rely on sysprops or statics.
> Uwe
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> eMail:
> From: Shai Erera []
> Sent: Tuesday, April 13, 2010 5:27 PM
> To:
> Subject: Proposal about Version API "relaxation"
> Hi
> I'd like to propose a relaxation on the Version API. Uwe, please  
> read the entire email before you reply :).
> I was thinking, following a question on the user list, that the  
> Version-based API may not be very intuitive to users, especially  
> those who don't care about versioning, as well as very inconvenient.  
> So there are two issues here:
> 1) How should one use Version smartly so that he keeps backwards  
> compatibility. I think we all know the answer, but a Wiki page with  
> some "best practices" tips would really help users use it.
> 2) How can one write sane code, which doesn't pass versions all over  
> the place if: (1) he doesn't care about versions, or (2) he cares,  
> and sets the Version to the same value in his app, in all places.
> Also, I think that today we offer a flexibility to users, to set  
> different Versions on different objects in the life span of their  
> application - which is a good flexibility but can also lead people  
> to shoot themselves in the legs if they're not careful -- e.g.  
> upgrading Version across their app, but failing to do so for one or  
> two places ...
> So the change I'd like to propose is to mostly alleviate (2) and  
> better protect users - I DO NOT PROPOSE TO GET RID OF Version :).
> I was thinking that we can add on Version a DEFAULT version, which  
> the caller can set. So Version.setDefault and Version.getDefault  
> will be added, as static members (more on the static-ness of it  
> later). We then change the API which requires Version to also expose  
> an API which doesn't require it, and that API will call  
> Version.getDefault(). People can use it if they want to ...
> Few points:
> 1) As a default DEFAULT Version is controversial, I don't want to  
> propose it, even though I think Lucene can define the DEFAULT to be  
> the latest. Instead, I propose that Version.getDefault throw a  
> DefaultVersionNotSetException if it wasn't set, while an API which  
> relies on the default Version is called (I don't want to return  
> null, not sure how safe it is).
> 2) That DEFAULT Version is static, which means it will affect all  
> indexing code running inside the JVM. Which is fine:
> 2.1) Perhaps all the indexing code should use the same Version
> 2.2) If you know that's not the case, then pass Version to the API  
> which requires it - you cannot use the 'default Version' API --  
> nothing changes for you.
> One case is missing -- you might not know if your code is the only  
> indexing code which runs in the JVM ... I don't have a solution to  
> that, but I think it'll be revealed pretty quickly, and you can  
> change your code then ...
> So to summarize - the current Version API will remain and people can  
> still use it. The DEFAULT Version API is meant for convenience for  
> those who don't want to pass Version everywhere, for the reasons I  
> outlined above. This will also clean our test code significantly, as  
> the tests will set the DEFAULT version to TEST_VERSION_CURRENT at  
> start ...
> The changes to the Version class will be very simple.
> If people think that's acceptable, I can open an issue and work on it.
> Shai

View raw message