lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Earwin Burrfoot <>
Subject Re: Lucene's default settings & back compatibility
Date Fri, 22 May 2009 10:44:03 GMT
> A funny thought: we can give those methods/classes really stupid/nasty names, to emphasize
the beauty of the existing API, to encourage people to stick with the better API :)
I believe I've seen google using internally names like
thisisbadbadbadInstanceMap. :)

> One thing we didn't address here fully are methods added to
> interfaces/abstract classes. When we add a method to an abstract class with
> a default impl, that's ok. But what if we need to make it abstract (like we
> had to do in 1575 for the Collector versions)?
If we adopt such relaxed back-compat policies, we'll no longer need
that abstract-class-as-an-interface craziness. If I remember well,
major point of using abstract VS interfaces, is that you can add
methods on user-extensible things and be jar drop-in compatible.

> If we could have the app saying something
> Version.getInstance(appId).actAsVersion(2.4) that would solve it because
> each will have its own Id, and the Version class would maintain a map
> between the Id and an instance. But I've still yet to resolve (in my mind)
> how the Lucene code will use it, since the same code runs in two apps with
> different IDs, and so won't know which appId to pass.
There's no practical difference between passing your version
everywhere, or your appId.. well.. everywhere.

> What if we continue to process Marvin's proposal on saving that information
> in the index. I think, Mike, that I asked you a similar question a while
> ago, about whether Lucene has the ability to store index versions. Index
> versions are important and can save some of the problems here - not just
> with storing stopwords list, but also code that manipulates the index, or
> makes decisions about scoring etc.
Storing metadata in the index is good idea by itself, but I believe
that should be done at your app level, not down inside Lucene. After
all, we all need different metadata.
There's that recently added commitUserData - very cool, even if I
don't need it. Would be nice to have indexUserData, which is preserved
across commits and has read/write methods.

> Arggh .. but again we face the same problem - how do we pass that
> information to the different classes? How is a TokenStream expected to read
> that info?
Yeah, absolutely, satellite lucene classes should not be bound to
physical instance of the index. I use the same analyzer to process
data for something like ten indexes. Which version number is going to
be used?
So we have to get the number from index manually and then pass it to
the classes in question. Which is absolutely the same as passing them
some version constant, or your appId.

> I think we may have to settle on the static Version class, even if it will
> read the information from the index (by doing some Version.init(File
> indexDir)).
As I said, my app uses around ten indexes, which one should I use? :)

Kirill Zakharenko/Кирилл Захаренко (
Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423
ICQ: 104465785

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

View raw message