Sorry Marc, I had missed your message. This is what I meant indeed.
On Fri, Dec 30, 2022 at 4:36 PM Greg Miller wrote:
>
> OK, great! Thanks Marc. I plan on merging the PR today.
>
> Cheers,
> -Greg
>
> On Thu, Dec 29, 2022 at 3:23 PM Marc D'Mello wrote:
>>
>> Hi Greg,
>>
>> I'm also OK merging
OK, great! Thanks Marc. I plan on merging the PR today.
Cheers,
-Greg
On Thu, Dec 29, 2022 at 3:23 PM Marc D'Mello wrote:
> Hi Greg,
>
> I'm also OK merging as is since this is a new feature and doesn't affect
> any of the current functionality. I also think there are no glaring issues
> with
Hi Greg,
I'm also OK merging as is since this is a new feature and doesn't affect
any of the current functionality. I also think there are no glaring issues
with the API in its current state. However, I do think that merging the
range and rangeonrange functionality makes sense and I like Adrien's
Hey Marc-
I don't want to speak for Adrien as he might have something different in
mind, but I think that's more-or-less the idea. I'm not sure the factory
methods belong on the LongRange/DoubleRange classes, or if separate classes
should be created for this purpose (which is more how I thought
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
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
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
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 wrote:
> Thank for the suggestion! I like the descriptiveness of it. My
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
Maybe "Range Intersect Faceting"?
On Mon, Dec 12, 2022 at 1:11 PM Greg Miller 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
10 matches
Mail list logo
