Well no one in their right mind is going to go to any solr version .0 unless you really just want to ruin your month and life waiting for version.5. Every single base solr release has a bunch of problems that get solved and I’m sure the true fields will come back as they have no overhead and cause no problems. As long as I will never be forced into solr cloud everything else seems reasonable except for removing a field type. Solr cloud simply doesn’t work well enough compared to raw machines and master slave configurations, or leader follower whatever the pc term is for it now.
The trie fields were enough to make work around for and they seem to work fine. They send the proper error if used incorrectly for the data being sent in, and your unit tests should be built in house to make sure expected input has expected output, and bad input results in bad output. Just an opinion but it has always worked for me. -David H > On Sep 29, 2025, at 10:55 AM, Jason Gerlowski <[email protected]> wrote: > > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
