Hi All,
I have below requirement for my business:
select?fl=*=MODIFY_TS:[2020-06-23T18:30:00Z TO *]=PHY_KEY2: "HQ010699" OR
PHY_KEY2: "HQ010377" OR PHY_KEY2: "HQ010396" OR PHY_KEY2: "HQ010399" OR
PHY_KEY2: "HQ010404" OR PHY_KEY2: "HQ010419" OR PHY_KEY2: "HQ010426" OR
PHY_KEY2: "HQ010452" OR
nately our documents now need to be grouped as well (product
> > variants into items) and that grouping query needs to work on that
> grouping
> > instead. As far as I'm aware you can't do nested grouping in Solr.
> >
> > In summary we want to have product variants that
"Unfortunately our documents now need to be grouped as well (product
variants into items) and that grouping query needs to work on that grouping
instead. As far as I'm aware you can't do nested grouping in Solr."
What about collapsing the product variants into a group Head which w
s into items) and that grouping query needs to work on that grouping
> instead. As far as I'm aware you can't do nested grouping in Solr.
>
> In summary we want to have product variants that get grouped into Items and
> then they get grouped by field and then sorted by another.
>
> T
(product
variants into items) and that grouping query needs to work on that grouping
instead. As far as I'm aware you can't do nested grouping in Solr.
In summary we want to have product variants that get grouped into Items and
then they get grouped by field and then sorted by another.
The solution
aggregation
framework which has aspects of both grouping and pivot faceting
* (nested) grouping/pivot faceting are building blocks that make Solr more
attractive for analytical workload and not just full-text search queries -
see http://blog.sematext.com/2013/11/09/presentation-solr-for-analytics/
Or am
Hey Martijn,
Did you find a good workaround?
Rih
On Sat, May 28, 2011 at 5:35 AM, Martijn Laarman mpdre...@gmail.com wrote:
Thanks Mike,
I've opened https://issues.apache.org/jira/browse/SOLR-2553 for this.
It's exciting to hear a workable implementation might be possible!
On Fri, May
Hi,
I was wondering if this issue had already been raised.
We currently have a use case where nested field collapsing would be really
helpful
I.e Collapse on field X then Collapse on Field Y within the groups returned
by field X
The current behavior of specifying multiple fields seem to be
I've found the same issue.
As long as I know, the only solution is to create a copy field which combines
both-fields values and facet on this field.
If one of the fields has a set of distinct values known in advance and its
cardinality c is not too big, it isn't a great problem: you can do with
Hi,
I was wondering if this issue had already been raised.
We currently have a use case where nested field collapsing would be really
helpful
I.e Collapse on field X then Collapse on Field Y within the groups returned
by field X
The current behavior of specifying multiple fields seem to be
Did you try pivot?
Bill Bell
Sent from mobile
On May 27, 2011, at 4:13 AM, Martijn Laarman mpdre...@gmail.com wrote:
Hi,
I was wondering if this issue had already been raised.
We currently have a use case where nested field collapsing would be really
helpful
I.e Collapse on field X
Can you open a Lucene issue (against the new grouping module) for
this?
I think this is a compelling use case that we should try to support.
In theory, with the general two-pass grouping collector, this should
be possible, but will require three passes, and we also must
generalize the 2nd pass
Thanks Mike,
I've opened https://issues.apache.org/jira/browse/SOLR-2553 for this.
It's exciting to hear a workable implementation might be possible!
On Fri, May 27, 2011 at 6:23 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Can you open a Lucene issue (against the new grouping
13 matches
Mail list logo
