On Thu, May 26, 2022 at 11:49 AM Greg Miller <gsmil...@gmail.com> wrote: > > 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...
Users don't deal with low level docvalues codec APIs, so I see this "as a user" as irrelevant, sorry. Higher-level classes (e.g. Field class) could impl it this way as implementation detail. > > ... 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. +1 to build a field class in sandbox, using BDV behind the scenes. I don't want to add any new DV types, trust me. I am just especially opinionated against multidimensional stuff pushed down to docvalues level, when it makes no sense from a DV perspective (column stride fields). If you have 3 dimensions of numbers, at a low level it would just make 3 columns at the end of the day anyway: IMO it would only make codec code more complicated with no benefit. So that's why I was listing out other alternatives. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
