[
https://issues.apache.org/jira/browse/LUCENE-8911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16883802#comment-16883802
]
Uwe Schindler edited comment on LUCENE-8911 at 7/12/19 1:22 PM:
----------------------------------------------------------------
I would not strictly enforce the old naming rules, because the idea behind the
NAME field is that the developer of a TokenStream component can decide for a
good name that unrelated to class name. E.g., this allows to restructure your
classes.
The new design was from the beginning made in a way that it's perfectly
possible to assign "alias" names for tokenstream components in the future.
E.g., we could deprecate an old name and rename something and temporary keep
both names for lookup. The NAME field only contains the new one.
This is basically the same: Let the developer decide for the name that fit's
best for his need. For backwards compatibility just keep the old name. For Solr
that's not an issue, as old schemas use class names anyways.
For Lucene-Internal components tis is not a problem, as we kept the old names -
but I'd like to possibly have the option to rename some of those in the future!
was (Author: thetaphi):
I would not strictly enforce the old naming rules, because the idea behind the
NAME field is that the developer of a TokenStream component can decide for a
good name that unrelated to class name. E.g., this allows to restructure your
classes.
The new design was from the beginning made in a way that it's perfectly
possible to assign "alias" names for tokenstream components in the future.
E.g., we could deprecate an old name and rename something and temporary keep
both names for lookup. The NAME field only contains the new one.
This is basically the same: Let the developer decide for the name that fit's
best for his need. For backwards compatibility just keep the old name.
For Lucene-Internal components tis is not a problem, as we kept the old names -
but I'd like to possibly have the option to rename some of those in the future!
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
