On Apr 13, 2010, at 11:09, Shai Erera <ser...@gmail.com> 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.
Andi..
> 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 <u...@thetaphi.de>
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
http://www.thetaphi.de
eMail: u...@thetaphi.de
From: Shai Erera [mailto:ser...@gmail.com]
Sent: Tuesday, April 13, 2010 5:27 PM
To: java-dev@lucene.apache.org
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
