lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-11917) A Potential Roadmap for robust multi-analyzer TextFields w/various options for configuring docValues
Date Fri, 26 Jan 2018 22:19:00 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message