[
https://issues.apache.org/jira/browse/SOLR-11917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341681#comment-16341681
]
Hoss Man commented on SOLR-11917:
---------------------------------
h2. Hoss'ss High Level Thoughts on these Goals / *U*secases
While it's certainly possible to takle some of these objectives independently
of the others, either from a standpoint of of incremental feature delivery, or
from a standpoint of "end user ease of use" there definitely seems to be some
overlap here that's worth considering.
In particular:
* While there is certainly some non-trivial set of possible implementations
that can satisfy both *U2.1* and *U2.2*, my gut impression is that no one
implementation will really fit both usecases well in an easy to use/understand
way. I'm also pretty confident that the "multi-language" use cases would be
easier to solve/build in a "clean" (and easy for users to understand) approach
more simply / quickly then any (non-silly) solutions that would support the
"let me shoot my self in the foot if I want" objectives.
* While I personally don't feel that the *U2.2* usecase is a particularly good
idea, the overall "plumbing" involved in supporting this type of usecase would
be very helpful towards supporting *U1.3*
* Likewise: *U1.1* and *U1.2* should be easy be implement as new FieldTypes
independent from the more complex needs of *U1.3*. But if *U1.3* was possible,
then there would likely be potential for refactoring to reduce common code and
simplify the implementations.
> A Potential Roadmap for robust multi-analyzer TextFields w/various options
> for configuring docValues
> ----------------------------------------------------------------------------------------------------
>
> Key: SOLR-11917
> URL: https://issues.apache.org/jira/browse/SOLR-11917
> Project: Solr
> Issue Type: Wish
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
> Assignee: Hoss Man
> Priority: Major
>
> A while back, I was tasked at my day job to brainstorm & design some "smarter
> field types" in Solr. In particular to think about:
> # How to simplify some of the "special things" people have to know about
> Solr behavior when creating their schemas
> # How to reduce the number of situations where users have to copy/clone one
> "logical field" into multiple "schema felds in order to meet diff use cases
> The main result of this thought excercise is a handful of usecases/goals that
> people seem to have - many of which are already tracked in existing jiras -
> along with a high level design/roadmap of potential solutions for these goals
> that can be implemented incrementally to leverage some common changes (and
> what those changes might look like).
> My intention is to use this jira as a place to share these ideas for broader
> community discussion, and as a central linkage point for the related jiras.
> (details to follow in a very looooooong comment)
> ----
> NOTE: I am not (at this point) personally committing to following through on
> implementing every aspect of these ideas :)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
