: 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]
