[
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883797#comment-16883797
]
Tomoko Uchida commented on LUCENE-8911:
---------------------------------------
Hi [~thetaphi],
thanks for your comment, I basically agree to your idea.
{quote}In addition to extracting the NAME field (which should not fail the SPI
lookup) also generate the "old name". Add both names to the map (they may
differ, if a user decides to use his own name).
{quote}
While we can strictly keep consistency of the (old) naming rule by this special
treatment, it looks slightly strange to me that a factory temporarily have two
names. When upgrading to 9.0.0, the client code that look up custom factories
by auto-generated names can be broken. It does not look good to me. The old
naming rule is not documented anywhere, as far as I know, so I think it is
rather an implementation than interface. Can't we discard the "old name" when
the NAME field is provided by the author?
I know It is not a big problem at all, I just need a bit more clear
interpretation for the "backwards compatibility" here and want to seek the
modest way to implement it.
> Backport LUCENE-8778 (improved analysis SPI name handling) to 8.x
> -----------------------------------------------------------------
>
> Key: LUCENE-8911
> URL: https://issues.apache.org/jira/browse/LUCENE-8911
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Reporter: Tomoko Uchida
> Priority: Minor
>
> In LUCENE-8907 I reverted LUCENE-8778 from the 8x branch.
> Can we backport it to 8x branch again, with transparent backwards
> compatibility (by emulating the factory loading method of Lucene 8.1)?
> I am not so sure about it would be better or not to backport the changes,
> however, maybe it is good for Solr to have SOLR-13593 without waiting for
> release 9.0.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
