> 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/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
