> 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.
Hmm, that's a different perspective than I had, but I understand where you're coming from and I think I agree. I think I'm so used to directly interacting with doc values that I haven't considered this point-of-view (that users should really commonly be interacting with DVs). As long as we provide a higher-level Field class that abstracts the implementation details, I think I'm on the same page with you here. > +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. Got it. +1 from me as well. I think we're in agreement. Thanks for the discussion! Cheers, -g On Thu, May 26, 2022 at 9:04 AM Robert Muir <rcm...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
