Hi,
I'm a bit unsure about what is being suggested. Is the idea to rename
range#LongRange and rangeonrange#LongRange to LongFieldFacets and
LongRangeFacets respectively and stick the static getters in there? In that
case, I also think that the idea makes a lot of sense and that it would
match our current range query API much better.
In addition, looking at document#LongRange, there are queries like
newContainsQuery() and newWithinQuery() that we can probably mimic to
avoid exposing RangeFieldQuery.QueryType to the user.
On Tue, Dec 13, 2022 at 5:04 PM Greg Miller <gsmil...@gmail.com> wrote:
> Thanks for the suggestion Adrien. I like this idea! Marc- what do you
> think?
>
> We might need to rework the package structure under the facets module to
> make this clean, but that might not be a terrible thing anyway. The
> existing sub-packages will make it challenging to get the visibility right.
> I think it would be ideal to flatten the package so we can reduce
> visibility of the class definitions and only expose the factory methods.
>
> Cheers,
> -Greg
>
> On Tue, Dec 13, 2022 at 01:18 Adrien Grand <jpou...@gmail.com> wrote:
>
>> I wonder if the facets actually require a different name, since they
>> look to me like a generalization of range facets for range fields,
>> while we previously only supported range facets on numeric fields. We
>> could keep calling them range facets?
>>
>> Maybe we could use the same model we used for queries by not exposing
>> query classes to users and providing factory methods, e.g. we could
>> have something like:
>>
>> public class LongFieldFacets {
>>
>> public static Facets getRangeFacetCounts(String field,
>> FacetsCollector hits, LongRange... ranges) {
>> return new LongRangeFacetCounts(...);
>> }
>>
>> }
>>
>> public class LongRangeFacets {
>>
>> // same function name
>> public static Facets getRangeFacetCounts(String field,
>> FacetsCollector hits, RangeFieldQuery.QueryType queryType,
>> LongRange... ranges) {
>> return new LongRangeOnRangeFacetCounts(...);
>> }
>>
>> }
>>
>> We'd still need to give a name for these classes, but the name would
>> be less important since these class names would be only for ourselves.
>> Users would never see them and refer to this new functionality as
>> range facets on range fields?
>>
>> On Mon, Dec 12, 2022 at 10:11 PM Gus Heck <gus.h...@gmail.com> wrote:
>> >
>> > In that case, maybe "Range Logic Faceting" ?
>> >
>> > Relation seems too broad and too overloaded elsewhere, makes me think
>> of RDBMS, related-ness, joins and such via word associations.
>> >
>> > On Mon, Dec 12, 2022 at 3:27 PM Greg Miller <gsmil...@gmail.com> wrote:
>> >>
>> >> Thank for the suggestion! I like the descriptiveness of it. My only
>> hesitation is that is supports more than range intersection based on the
>> provided QueryType instance (e.g., within, contains). I _imagine_ that
>> intersection will be most common, but I don’t really know of course. I
>> thought about generalizing your suggestion to something like “Range
>> Relation Faceting,” but fear that would be confusing.
>> >>
>> >> Thanks again!
>> >>
>> >> Cheers,
>> >> -Greg
>> >>
>> >> On Mon, Dec 12, 2022 at 10:19 Gus Heck <gus.h...@gmail.com> wrote:
>> >>>
>> >>> Maybe "Range Intersect Faceting"?
>> >>>
>> >>> On Mon, Dec 12, 2022 at 1:11 PM Greg Miller <gsmil...@gmail.com>
>> wrote:
>> >>>>
>> >>>> Folks-
>> >>>>
>> >>>> Naming is hard! (But you all know that already).
>> >>>>
>> >>>> Marc D'Mello and I have been working on a new faceting
>> implementation that's meant to complement Lucene's existing range-relation
>> queries (e.g., LongRange#newIntersectsQuery, DoubleRange#newContainsQuery,
>> LongRangeDocValuesField#newSlowIntersectsQuery, etc.). Well, I should say
>> Marc is working on the change and I'm just providing nit-picky feedback on
>> his PR, which is here: https://github.com/apache/lucene/pull/11901. The
>> general idea of this feature is to allow users to get facet counts for
>> these sorts of range-relation filters before they're applied. For example,
>> if a user is indexing ranges with their documents, they may have a set of
>> query-ranges they want to facet on, based on some range relationship (e.g.,
>> intersection, contains, etc.).
>> >>>>
>> >>>> As a concrete example, imagine that documents contain a price range
>> (maybe a document represents some e-commerce product but the price varies
>> based on some configuration options), and a user wants to build a price
>> range filter that applies filtering based on whether-or-not the two ranges
>> intersect (i.e., DoubleRange#newIntersectsQuery to apply a price range
>> filter). This user wants faceting capabilities over the different price
>> ranges they want to make available, so they need a way to facet over a list
>> of provided query-ranges, based on the "intersect" relationship with the
>> doc-encoded ranges. That's what Marc's "RangeOnRange" faceting is trying to
>> accomplish.
>> >>>>
>> >>>> In my opinion, the PR is really close to being ready (thanks again
>> Marc!), but I'm wondering if we can come up with a more descriptive name.
>> As it currently stands, the feature is termed "RangeOnRange Faceting,"
>> which feels just a bit wonky to me. That said, I can't really come up with
>> anything better.
>> >>>>
>> >>>> ** Does anyone have suggestions on a better name? **
>> >>>>
>> >>>> Any / all suggestions appreciated! (And of course, any other input
>> on the PR is welcome if anyone is interested).
>> >>>>
>> >>>> Cheers,
>> >>>> -Greg
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> http://www.needhamsoftware.com (work)
>> >>> http://www.the111shift.com (play)
>> >
>> >
>> >
>> > --
>> > http://www.needhamsoftware.com (work)
>> > http://www.the111shift.com (play)
>>
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
