lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sanne Grinovero <>
Subject Re: Having a default constructor in Analyzers
Date Mon, 08 Feb 2010 10:35:39 GMT
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

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,

2010/2/8 Uwe Schindler <>:
> 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):
> 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
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
> Uwe
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message