)
is it acceptable to have
doc1 (shard 1)
whatever (shard 2)
yeah (shard 3)
for a join of
- user15, doc1
- user16, whatever
- user17, yeah
or do all the results of the main query need to reside on the same shard as
all the results of join.
Hopefully that's an understandable question.
Thanks,
slevytam
as the parent document, if I knew how.
Thanks,
slevytam
--
View this message in context:
http://lucene.472066.n3.nabble.com/Joins-with-SolrCloud-tp4073199p4075310.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hi Erick,
I actually did mean collapse.field, as per:
http://blog.trifork.com/2009/10/20/result-grouping-field-collapsing-with-solr/
On high level I am trying to avoid the use of a join between a list of
entries and a list of actions that users have performed on a entry (since
it's not supported
this?
Thanks,
slevytam
--
View this message in context:
http://lucene.472066.n3.nabble.com/Field-Query-After-Collapse-Field-tp4073691p4073972.html
Sent from the Solr - User mailing list archive at Nabble.com.
Unfortunately not. That would require an object for every single entry for
every single user.
Generating millions of basically empty objects just for this query is likely
impossible.
:(
--
View this message in context:
which yields:
ex. entry_id, entry_starred, entry_read
But if I try to do a fq on one of the fields
ex. fq=!entry_read:1
The fq is performed before the collapse leading to incorrect results.
Is there anyway to perform the field query after the results are collapsed?
Thanks,
slevytam
--
View
