gerlowskija commented on PR #3922: URL: https://github.com/apache/solr/pull/3922#issuecomment-4262920611
I spent some time reviewing the "schema" package part of this. (Put differently - I skipped the bulk of the PR related to doc-values changes). I also got to talk to Houston a bit offline about the overall design and what next steps are. I'm gonna try to summarize that conversation here. @HoustonPutman - correct me if I misunderstood what we discussed. - Right now this PR includes the 'enhancedIndex' stuff on both the existing FooPointField implementations, and on a totally new set of parallel implementations that extend from NumericField: IntField, LongField, DoubleField, etc. - But exposing this stuff on the FooPointField impl's creates a complication for upgrading users - in a way it's cleaner if `FooPointField` and friends remain untouched, and for the new termsIndex+BKD setup to be offered in the new field types only. Houston and I were leaning towards making that change in our discussion earlier today. - Since IntField, LongField, etc. are brand new, they're free to enable termsIndex+BKD right out of the gate. We discussed whether these new fields should always be termsIndex+BKD, or whether it was worth having flags or schema-settings similar to the 'enhancedIndex' flag in the current PR that would allow users to opt for BKD-only or termsIndex-only. We were leaning towards "no additional flags" under the assumption that numeric fields aren't typically big drivers of index-size and so the large majority of folks were unlikely to need access to such low level control. - If the plan in the bullets above is followed, existing Point fields could be deprecated and they and Trie's could both be removed in a subsequent major release! - [This is where my understanding is haziest] A huge chunk of the current PR consists of an attempt to unify the Lucene types that Solr users to represent and work with docValues in numeric fields. This seemed a promising improvement but ended up hitting an unresolvable log-jam around in-place updates. So ultimately a big chunk of this PR is going to disappear and isn't worth review attention at this point. Hopefully that gives a good sketch for what @HoustonPutman is thinking in terms of next steps! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
