|
|
-
Re: 3.4.0 draft release notes
Bernd Fehling 2011-09-10, 14:21
Will the fix/patch for issue SOLR-2726 included in SOLR 3.4.0? ----- Ursprüngliche Nachricht ----- Von: Michael McCandless <[EMAIL PROTECTED]> Datum: Freitag, 9. September 2011, 20:50 Betreff: 3.4.0 draft release notes An: Lucene/Solr dev <[EMAIL PROTECTED]> > I just took a first crack at them: > > http://wiki.apache.org/solr/ReleaseNote34> http://wiki.apache.org/lucene-java/ReleaseNote34> > Feel free to go improve them before we release! > > Mike McCandless > > http://blog.mikemccandless.com> > ----------------------------------------------------------------- > ---- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > ---------------------------------------------------------------------
-
Re: 3.4.0 draft release notes
Michael McCandless 2011-09-11, 23:04
On Sat, Sep 10, 2011 at 10:21 AM, Bernd Fehling <[EMAIL PROTECTED]> wrote: > Will the fix/patch for issue SOLR-2726 included in SOLR 3.4.0? Sorry, no. This isn't a release blocker issue. But, separately, I think we should fix it, but on quick glance it doesn't look like there's consensus on how to fix it? Mike McCandless http://blog.mikemccandless.com---------------------------------------------------------------------
-
Re: 3.4.0 draft release notes
Robert Muir 2011-09-11, 23:12
On Sun, Sep 11, 2011 at 7:04 PM, Michael McCandless <[EMAIL PROTECTED]> wrote: > On Sat, Sep 10, 2011 at 10:21 AM, Bernd Fehling > <[EMAIL PROTECTED]> wrote: > >> Will the fix/patch for issue SOLR-2726 included in SOLR 3.4.0? > > Sorry, no. > > This isn't a release blocker issue. > > But, separately, I think we should fix it, but on quick glance it > doesn't look like there's consensus on how to fix it? >
I had this same bug when implementing a spellchecker too. Its something the spellcheck framework expects, but doesn't provide.
I think its broken that SolrSpellChecker has both field name and analyzer, but only sets up field name in its init()... if SolrSpellChecker is going to own the 'analyzer' variable then I think its init() should take care of the logic, currently its either duplicated across spellchecker implementations, or its missing entirely, causing bugs like SOLR-2726. -- lucidimagination.com
---------------------------------------------------------------------
-
Re: 3.4.0 draft release notes
Bernd Fehling 2011-09-13, 18:53
Hmm, it may be not an blocker issue but still has a NPE which isn't good publicity for solr/lucene. This is already fixed with a patch attached to SOLR-2726. And yes, it is fixed with its init(). So where is the problem?
----- Ursprüngliche Nachricht ----- Von: Robert Muir <[EMAIL PROTECTED]> Datum: Montag, 12. September 2011, 1:13 Betreff: Re: 3.4.0 draft release notes An: [EMAIL PROTECTED]
> On Sun, Sep 11, 2011 at 7:04 PM, Michael McCandless > <[EMAIL PROTECTED]> wrote: > > On Sat, Sep 10, 2011 at 10:21 AM, Bernd Fehling > > <[EMAIL PROTECTED]> wrote: > > > >> Will the fix/patch for issue SOLR-2726 included in SOLR 3.4.0? > > > > Sorry, no. > > > > This isn't a release blocker issue. > > > > But, separately, I think we should fix it, but on quick glance it > > doesn't look like there's consensus on how to fix it? > > > > I had this same bug when implementing a spellchecker too. > Its something the spellcheck framework expects, but doesn't provide. > > I think its broken that SolrSpellChecker has both field name and > analyzer,but only sets up field name in its init()... if > SolrSpellChecker is > going to own the 'analyzer' variable then > I think its init() should take care of the logic, currently its either > duplicated across spellchecker implementations, > or its missing entirely, causing bugs like SOLR-2726. > > > -- > lucidimagination.com > > ----------------------------------------------------------------- > ---- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
---------------------------------------------------------------------
-
Re: 3.4.0 draft release notes
Robert Muir 2011-09-13, 19:02
On Tue, Sep 13, 2011 at 2:53 PM, Bernd Fehling <[EMAIL PROTECTED]> wrote: > Hmm, it may be not an blocker issue but still has a NPE which isn't > good publicity for solr/lucene. > This is already fixed with a patch attached to SOLR-2726. > And yes, it is fixed with its init(). > So where is the problem?
As i explained both in this thread and on the jira issue, the proper fix is for the logic to be in *SolrSpellChecker*, since its the one that has this 'analyzer' variable.
then the logic doesnt need to be duplicated across n implementing classes (AbstractLuceneSpellChecker, DirectSpellChecker, Suggester, ...)
-- lucidimagination.com
---------------------------------------------------------------------
|
|