[ 
https://issues.apache.org/jira/browse/SOLR-9467?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15888964#comment-15888964
 ] 

David Smiley commented on SOLR-9467:
------------------------------------

If {{useDocValuesAsStored}} was generalized to a hypothetical 
{{excludeFromWildcardRetrieval}} (damn it's hard to come up with good names for 
this!) then it could not only work as it does now but also for stored fields.  
To me that feels better than removing the stored fields as a doc transformer 
because by that time, all that text has wound up in the document cache already 
-- and you don't always want that.  See: SOLR-10117   But sometimes you do, 
granted.  Another reason besides highlighting to want large fields _out_ of the 
doc cache is to support atomic updates.

BTW a field that one might want to remove from {{fl=*}} would almost certainly 
_not_ have docvalues, so I think a performance discussion about the comparison 
isn't applicable.

> Document Transformer to Remove Fields
> -------------------------------------
>
>                 Key: SOLR-9467
>                 URL: https://issues.apache.org/jira/browse/SOLR-9467
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: SearchComponents - other
>    Affects Versions: 6.2
>            Reporter: Gus Heck
>         Attachments: SOLR-9467.patch, SOLR-9467.patch
>
>
> Given that SOLR-3191 has become bogged down and inactive, evidently stuck in 
> low level details, and since I have wished several times for some way to just 
> get that one big field out of my results to improve transfer times without 
> making a big brittle list of all my other fields. I'd like to propose a 
> DocumentTransformer that accomplishes this.
> It would look something like this:
> {code}&fl=*,[fl.rm v="title"]{code} 
> Since removing one field with a known name is probably the most common case 
> I'd like to start by keeping this simple, and if further features like globs 
> or lists of fields are desired, subsequent Jira tickets can be opened to add 
> them. Not attached to specifics here, only looking to keep things simple and 
> solve the key use case. If you don't like fl.rm as a name for a transformer, 
> suggest a better one (for example). 



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to