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
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
On Mon, Feb 8, 2010 at 9:31 AM, Sanne Grinovero
wrote:
> 2010/2/8 Robert Muir :
> >8 snip 8<
>>
>> how would this work when the Query analyzer differs from the Index analyzer?
>> For example, using commongrams in solr means you use a different Query
>> analyzer from Index analyzer, and the
2010/2/8 Robert Muir :
>8 snip 8<
>
> how would this work when the Query analyzer differs from the Index analyzer?
> For example, using commongrams in solr means you use a different Query
> analyzer from Index analyzer, and there are some other use cases even in
> solr (synonyms expansion a
DM Smith:
> Imagine that each index maintains a manifest of the toolchain for the index,
> which includes the version of each part of the chain. Since the index is
> created all at once, this probably is the same as the version of lucene.
> When the user searches the index the manifest is consulte
> > Also, wouldn't it make sense to be able to read the recommended
> > version from the Index?
>
> Absolutely!
>
>
how would this work when the Query analyzer differs from the Index analyzer?
For example, using commongrams in solr means you use a different Query
analyzer from Index analyzer, and t
On Feb 7, 2010, at 5:32 PM, Sanne Grinovero wrote:
> Does it make sense to use different values across the same
> application? Obviously in the unlikely case you want to threat
> different indexes in a different way, but does it make sense when
> working all on the same index?
I think it entirel
Does it make sense to use different values across the same
application? Obviously in the unlikely case you want to threat
different indexes in a different way, but does it make sense when
working all on the same index?
If not, why not introduce a value like "Version.BY_ENVIRONMENT" which
is statica
On Sun, Feb 7, 2010 at 8:38 PM, Robert Muir wrote:
> Simon, can you explain how removing CURRENT makes it harder for users to
> upgrade? If you mean for the case of people that always re-index all
> documents when upgrading lucene jar, then this makes sense to me.
That is what I was alluding to!
N
Simon, can you explain how removing CURRENT makes it harder for users to
upgrade? If you mean for the case of people that always re-index all
documents when upgrading lucene jar, then this makes sense to me.
I guess as a step we can at least deprecate this thing and strongly
discourage its use, pl
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 r
ok, I think you have a valid case for using this for testing. We just have
to be careful about wording and such, because i think right now we encourage
users to use this constant. I created a patch to make it scary and
deprecated under LUCENE-2080, we don't have to remove the constant just keep
it
Thanks for all the quick answers;
finding the ctor having only a Version parameter is fine for me, I had
noticed this "frequent pattern" but didn't understand that was a
general rule.
So can I assume this is an implicit contract for all Analyzers, to
have either an empty ctor or a single-parameter
I propose we remove LUCENE_CURRENT completely, as soon as TEST_VERSION is
done.
On Sun, Feb 7, 2010 at 12:53 PM, Uwe Schindler wrote:
> Hi Sanne,
>
> Exactly that usage we want to prevent. Using Version.LUCENE_CURRENT is the
> badest thing you can do if you want to later update your Lucene versi
.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Uwe Schindler [mailto:u...@thetaphi.de]
> Sent: Sunday, February 07, 2010 6:54 PM
> To: java-dev@lucene.apache.org
> Subject: RE: Having a default construct
Hi Sanne,
Exactly that usage we want to prevent. Using Version.LUCENE_CURRENT is the
badest thing you can do if you want to later update your Lucene version and do
not want to reindex all your indexes (see javadocs).
It is easy to modify your application to create analyzers even from config
fi
Almost no Analyzer has a default ctor anymore due to the introduction
of Version. This should not be an issue for API users loading
Analyzers per reflection. You can still call the version Ctor
alternatively. Providing a default ctor with the current version could
be very risky in many regards, a b
17 matches
Mail list logo
