Going to throw my two cents in, only thing that comes to mind is a dynamic field definition that may be stored but is also incredibly large, I would use such a field for storing tokenized versions of a field that use stop words and multi word values for use in post processing projects like mlt so “the red fox jumps over the bridge” could be stored as “Red red_fox fox red_fox_jumps fox_jumps jumps fox_jumps_over over jumps_over jumps_over_bridge over_bridge bridge” or something, and you only want this dynamic field called if explicitly called for to prevent massive output when it isn’t needed? Figure a 2000 word text field stored then retokenized as above could easily quadruple depending on settings, and what a mess of an output to something human readable, not that it shouldn’t be interpreted after the fact but a generic query from solr would be massive and useless to a human but valuable to a machine that knew what it was looking for.
> On Nov 10, 2026, at 5:01 AM, Alessandro Benedetti <[email protected]> > wrote: > > Left a comment there and added my colleague Andrea for visibility (he > worked a lot on that... 13 years ago xD). > I honestly don't like the schema property route much, unless we first > support the query time get parameter option first. > Super happy to discuss and understand why you (impersonal) believe the > schema support should be done and why before the excluded syntax support at > query time. > > Cheers > -------------------------- > *Alessandro Benedetti* > Director @ Sease Ltd. > *Apache Lucene/Solr Committer* > *Apache Solr Chair of PMC* > > e-mail: [email protected] > > > *Sease* - Information Retrieval Applied > Consulting | Training | Open Source > > Website: Sease.io <http://sease.io/> > LinkedIn <https://linkedin.com/company/sease-ltd> | Twitter > <https://twitter.com/seaseltd> | Youtube > <https://www.youtube.com/channel/UCDx86ZKLYNpI3gzMercM7BQ> | Github > <https://github.com/seaseltd> > > >> On Tue, 10 Nov 2026 at 07:10, David Smiley via dev <[email protected]> >> wrote: >> >> Sharing for visibility... >> https://issues.apache.org/jira/browse/SOLR-3191 old issue that fizzled but >> lots of interest! In essence, the proposal there is a syntax in "fl" to >> remove a field like a leading minus. I filed another issue (perhaps >> duplicative) that takes a different approach: >> https://issues.apache.org/jira/browse/SOLR-18592 involving a >> "matchesWildcard" flag on fields in the schema. Feedback welcome! >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
