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 c
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 rea
: 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 TrieFiel
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.
On Fri, Sep 26, 2025 at 12:10 AM Rahul Goswami
wrote:
> Personally, I would really prefer the Trie fields
Personally, I would really prefer the Trie fields not be removed entirely.
It allows me to reindex in-place without service disruption and without
needing additional hardware (even temporarily) since I can continue with
the same schema.
Maybe we can leave these as is if they don't contribute to an
: With 10 starting to loom, me and Claude went and looked for code that could
be removed. Here is what we found:
:
https://cwiki.apache.org/confluence/display/SOLR/Solr+10+Deprecation+Removal+Opportunities
You two are my newest favorite people.
: I was thinking of teeing up a single JIRA with