On Thu, May 20, 2010 at 3:07 PM, Chris Hostetter <[email protected]> wrote: > FWIW: the other thing you may not be aware of is that schema.xml has > always had a "version" attribute on the top level <schema/> declaration > that also dictates some default behavior. For example: initially all solr > fields were multiValued by default, but if you have version="1.1" (or > higher) then the "default" value for the multiValued property of fields > changes. > > it's one more peice of flexability that the factories have when deciding > what tokenizer/filter to produce in the goal of backcompatibility (but > sensible defaults)
You are right, I was unaware of this. But i'm confused that its currently 1.3. I guess what I am looking for overall is something more like this: * Version is everywhere in analyzers but mostly for two reasons: bug-back-compat, and defaults. * The analyzers module has its own version numbers (so you drop in an old one for the same bytecode=backcompat). * This isn't a free-for-all, we try to implement backwards compatibility, at least across minor releases, in the sense that we just dont go hog-wild, to keep upgrades easy. * At the same time, the concept of bug-back-compat goes away, if we fix a bug, we fix a bug. If you want precise back compat you use the old jar file. The issue of improving defaults generally sits inside actual lucene Analyzer (or the equivalent "schema example" for Solr), but usually not in the TokenStreams themselves. To deal with improved defaults in this new modularized world, I feel that we just shouldnt have so many concrete Analyzers in java that really should be "examples" Instead, an idea is that as we migrate the Solr analysis factories to the analyzer module, we also produce "artifacts" which are starter examples of how to do analysis for Solr users. I'd like to be able to just have these, and rid of the concrete Java implementations entirely. Perhaps for ease of use, a Java user could actually get a "Analyzer" at runtime from one of these example definitions (and use this declarative mechanism in a non-Solr app too). They should still be able to extend Analyzer themselves like they do today, but I don't think we should provide examples in two different languages: Java code and XML. I feel this would give us enough flexibility to get rid of Version, and at the same time keep the API consistent and make upgrading easy. (This still isn't a concrete proposal at all, just some random thoughts) -- Robert Muir [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
