[ 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