I agree that technically it's just as good. I also think it's less clear for a user. The concept of "points" is something we've established in Lucene, so I think it makes sense for users to think about indexing points as a doc value as opposed to having to manage multiple fields for all their dimensions in this sort of unsorted field. But that's just my opinion as a user. But that's maybe a bit philosophical at this point and I think we can "agree to disagree" for now because...
... just to be clear, I'm _not_ suggesting we add a new doc value type at this time. I'm not even necessarily advocating that we ever add it. I think it's perfectly reasonable to define a new Field class that builds on top of BDV (as Marc has done in his PR) that allows users to add "point" fields to their documents that get indexed as doc values (using BDV). This is very similar to LatLonDocValuesField, LongRangeDocValuesField, etc. Is that an acceptable approach to you, or are you advocating that we shouldn't do that and should instead create these new "unsorted" numeric fields now? I'm even fine if we put this in the sandbox module for now while we "kick the tires." In fact, I think I'd advocate for that. Thanks again for the feedback. It forced a deep examination of this idea, which I appreciate. Cheers, -g On Wed, May 25, 2022 at 11:41 AM Robert Muir <rcm...@gmail.com> wrote: > > On Wed, May 25, 2022 at 2:08 PM Greg Miller <gsmil...@gmail.com> wrote: > > > > > > I guess with an “unsorted” numeric DV type we could get there with aligned > > indices, as you describe, but that seems less appealing than supporting > > multi-dim points directly. > > > > Name one technical reason why? > Unsorted would be exactly just as good, except also more general > purpose. The number of docvalues types should be kept to a strict > minimum, and should be generally useful to a variety of common > use-cases. Each type has a huge maintenance cost, and never goes away. > Every codec must implement every type. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
