At least originally we decided to keep Trie fields around because they were faster for certain types of searches. I think Tries were faster for range queries, but Points excelled at single-value lookups?
Did we (or Lucene) ever address that in some way? Are Tries still better for certain types of queries? That seems like an important question to answer before any discussion of moving or removing them... Best, Jason On Sat, Sep 27, 2025 at 7:31 AM David Eric Pugh <[email protected]> wrote: > > Hoss, I had a conversation with David (on the phone) about just that idea, > of moving some things to solr-sandbox, so I am definitely receptive to it. > TrieField is a good example of one who is maybe okay just "hiding" in the > source tree. > One issue with moving it to sandbox is that we don't really have releases > from there, correct? I think for me, the effort is "Does spinning up the > tooling to release Trie as a module" overwhelm the "Hey, fewer workarounds". > At least for me, it's not on my immediate "hit list" for removal to Solr 10. > But the moment it holds anything up specific... Then that calculus > changes for me. Now, if I can just move them to solr-sandbox and not provide > any release tooling around, that makes it more attractive. Not sure how much > of a issue that would be to current users like Rahul however... > Also, we really just need to fix the underlying reason you like TrieFields, > which is the updating issue! > On Friday, September 26, 2025 at 07:11:19 PM EDT, Chris Hostetter > <[email protected]> wrote: > > > : I'd prefer to see Trie fields hang out a bit longer. These fields are > : proper plugins (i.e. they subclass types), so their presence is relatively > : minor for their project maintenance impact. > > Hrm, sort of? > > 1) There is a lot cruft sprinkled through out the codebase for dealing > with TrieFields -- most of it is in faceting, but there is also weird > little hacks like a workaround for SOLR-9809 in DocumentBuilder > > hossman@slate:~/lucene/solr [j21] [main] $ find -name \*.java | grep -v test > | grep -v '/schema/' | xargs grep -E > 'TrieField|Trie(Date|Double|Float|Int|Long)Field' | wc -l > 42 > > > 2) We currently randomize the use of Trie numeric fields in 20% of our > test runs -- which means means 20% less testing of fields we actually want > people to use. > > > 3) Because of #2, any time someone tries to add new code and runs into a > werid quirk with Trie fields, it either has to be fixed, or hacked around > (see #1) > > > At some point, we have to accept that it's time to pull a Marie Kondo, > thank the Trie fields, and send them on their way. > > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
