Hi Uwe, yes Hibernate is definitely recommending the Solr way for normal and power users, but we're also taking care of beginners trying it out for the first time it should just work out of the box for a simple POC, in those cases an Analyzer is defined as global analyzer (used for all cases you're not overriding the default); in this case it used to be possible to specify a single Analyzer by fully qualified name, to be used globally, or one "per index". Of course this is far from the flexibility needed for most real world applications, but keeps it simple for beginners taking a first look to introducing Lucene; so for these cases I don't care much about the Version used, of course it's important that they later can pin it down. To be compatible I'll have to change the loader, which is going to look for a default constructor, or a single-parameter Version constructor, should be good enough to accomodate the simple goal; I'll read the Version from a configuration parameter, probably nailing down the Version to the current latest and/or reading my own environment parameter.
I agree about the factory strategy; in fact it's on HSEARCH-457 since right before my emails here; I asked here to check we could keep it simple :-) Thanks all, Sanne 2010/2/8 Uwe Schindler <u...@thetaphi.de>: > Simon: >> Sanne, I would recommend you building a Factory pattern around you >> Analyzers / TokenStreams similar to what solr does. That way you can >> load you own "default ctor" interface via reflection and obtain you >> analyzers from those factories. That makes more sense anyway as you >> only load the factory via reflection an not the analyzers. > > As far as I see, Hibernate uses Solr Factories. On the other hand, you can > instead of creating your own SolrAnalyzer also use a "standard" one from > Lucene (you can do this in Solr, too): > > http://docs.jboss.org/hibernate/stable/search/reference/en/html_single/#analyzer > > In my opinion, the Factory pattern is ok for own analyzer definitions. For > reusing "standard" analyzers like "StandardAnalyzer" or "TurkishAnalyzer", > the ideal case is to use the reflection code I proposed before. This code > works for all language-based analyzers having a standard ctor or Version > ctor. Solr will also handle this reflection-based instantiation with optional > Version parameter in future, too (Eric Hatcher pointed that out to me, when > working on SOLR-1677: "Another comment on this... Solr supports using an > Analyzer also, but only ones with zero-arg constructors. It would be nice if > this Version support also allowed for Analyzers (say SmartChineseAnalyzer) to > be used also directly. I don't think this patch accounts for this case, does > it?"). > > As Hibernate also uses the factory pattern for custom analyzers, as soon as > https://issues.apache.org/jira/browse/SOLR-1677 is in, the version problem > for those should be solved, too (as you can specify the parameter to each > component). But Hibernate should also think about a global default Version > (like Solr via CoreAware or like that), that is used as a default param to > all Tokenizers/TokenFilters and when reflection-based Anaylzer subclass > instantiation is used. > > By the way, hibernate's reuse of Solr's schema is one argument of Hoss, not > to make it CoreAware. > > Uwe > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
