apability? What part of
> developer documentation would be suitable for this?
>
> Regards,
> Imran
>
> Sent from Mail for Windows 10
>
> From: Joel Bernstein
> Sent: Thursday, July 6, 2017 7:40 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Joins in Parallel SQ
Is it possible to contribute towards building this capability? What part of
developer documentation would be suitable for this?
Regards,
Imran
Sent from Mail for Windows 10
From: Joel Bernstein
Sent: Thursday, July 6, 2017 7:40 AM
To: solr-user@lucene.apache.org
Subject: Re: Joins in Parallel
Joins and OFFSET are not currently supported with Parallel SQL.
The docs for parallel SQL cover all the supported features. Any syntax not
covered in the docs is likely not supported.
Joel Bernstein
http://joelsolr.blogspot.com/
On Thu, Jul 6, 2017 at 2:40 PM, wrote:
>
> Is it possible to join
Hi, Sorry that this reply is not an answer for your post, but want to know
whether graph is working fine for you as expected. is that traverse working
fine in the graph ?
I posted a question over here,
http://lucene.472066.n3.nabble.com/Graph-traversel-td4331207.html#a4331799
but no response.
S
You can also do the innerJoin in parallel across worker nodes using the
parallel function:
hashJoin(
parallel(workerCollection,
innerJoin(
search(users, q="*:*",
fl="userId, full_name, hometown", sort="userId a
Something I forgot to mention - the collection shards can live on any
number of machines, anywhere in the world. As long as the clusterstate in
zk knows where the shard can be found (ie, a basis of SolrCloud) then
everything will work. The example I gave had the shards living on the same
machine bu
Mugeesh,
You can use Streaming Aggregation to provide various types of
cross-collection joins. This is currently available in trunk and will be a
part of Solr 6.
To follow with your example, let's assume the following setup:
Restaurants: avail on machine1:8983 with 3 shards, zk at zk1:2345
Users:
The question as I read it was composite documents, not cross-collection
joins.
If the joined core is small enough to be replicated across all replicas
of your main collection, then cross-core joining works well, as it is
all within one instance.
As to composite documents, I have sometimes wondere
True, I haven't looked at it closely. Not sure where it is in the
priority list though.
However, I would recommend you _really_ look at _why_ you
think you need cross-collection joins. Likely they will be expensive,
and whether they're performant in your situation will be a question.
If at all p
https://issues.apache.org/jira/browse/SOLR-7090
I see this jira open in support of joins which might solve the problem.
On Sun, Aug 16, 2015 at 2:51 PM, Erick Erickson
wrote:
> bq: Is there any chance of this feature(merge the results to create a
> composite
> document) coming out in the next r
bq: Is there any chance of this feature(merge the results to create a composite
document) coming out in the next release 5.3
In a word "no". And there aren't really any long-range plans either that I'm
aware of.
You could also explore streaming aggregation, if the need here is more
batch-oriented
Is there any chance of this feature(merge the results to create a composite
document) coming out in the next release 5.3 ?
On Sun, Aug 16, 2015 at 2:08 PM, Upayavira wrote:
> You can do what are called "pseudo joins", which are eqivalent to a
> nested query in SQL. You get back data from one cor
You can do what are called "pseudo joins", which are eqivalent to a
nested query in SQL. You get back data from one core, based upon
criteria in the other. You cannot (yet) merge the results to create a
composite document.
Upayavira
On Sun, Aug 16, 2015, at 06:02 PM, Nagasharath wrote:
> I exactl
I exactly have the same requirement
> On 13-Aug-2015, at 2:12 pm, Kiran Sai Veerubhotla wrote:
>
> does solr support joins?
>
> we have a use case where two collections have to be joined and the join has
> to be on the faceted results of the two collections. is this possible?
You can potentially just use a text_general field, in which case your
comma separated words will be effectively a multi-valued field. I
believe that will work.
As to how you want to use joins, that isn't possible. They are pseudo
joins, not full joins. They will not be able to include data from th
Roman,
The video was very clarifying and I realized block joins would be a
great fit for my problem. However, I got worried about the size of the
block... I could have 10 million childs for 1 parent, for instance. Althout
this could stay in the same shard, do you guys think it would be a huge
Hello,
The joins are not the only idea, you may want to write your own function
(ValueSource) that can implement your logic. However, I think you should
not throw away the regex idea (as being slow), before trying it out -
because it can be faster than the joins. Your problem is that the number of
Yes, joins support distributed search fine,
provided that the individual documents that are joined reside on the same shard.
For example, if you are modeling blogs and posts (one blog object as many posts)
shard1
--
joe!blog_info
joe!post1
shard2
--
mary!blog_info
Hi Yonik,
Thanks for the reply. It was very helpful.
This may be a newb question but will this work on a individual rows of a
query or do all the queries' results need to be on the same shard.
ex.
if the main query would return
- user15 (shard 1)
- user16 (shard 2)
- user17 (shard 3)
is it a
On Wed, Jul 3, 2013 at 5:40 PM, slevytam wrote:
> Hi Yonik,
>
> Can you offer any insight as to how one might ensure that documents reside
> on the same shard as the document you'd like them to join.
>
> For example:
> I'd like to do a simple join of user actions to a specific document. So, i
> w
Hi Yonik,
Can you offer any insight as to how one might ensure that documents reside
on the same shard as the document you'd like them to join.
For example:
I'd like to do a simple join of user actions to a specific document. So, i
would query for a list of documents and have the user actions on
On Tue, Jun 25, 2013 at 7:55 PM, Upayavira wrote:
> However, if from your example, innerCollection was replicated across all
> nodes, I would think that should work, because all that comes back from
> each server when a distributed search happens is the best 'n' matches,
> so exactly how those 'n'
Thanks, confirmed by trying w/ 4.3.1 that the join works with the outer
collection distributed/sharded so long as the inner collection is not
distributed/sharded.
Chris
On Tue, Jun 25, 2013 at 4:55 PM, Upayavira wrote:
> I have never heard mention that joins support distributed search, so you
IRA above
-- James
-Original Message-
From: Upayavira [mailto:u...@odoko.co.uk]
Sent: Tuesday, June 25, 2013 7:55 PM
To: solr-user@lucene.apache.org
Subject: Re: Joins with SolrCloud
I have never heard mention that joins support distributed search, so you cannot
do a join against a sharded core.
H
I have never heard mention that joins support distributed search, so you
cannot do a join against a sharded core.
However, if from your example, innerCollection was replicated across all
nodes, I would think that should work, because all that comes back from
each server when a distributed search h
Martijn,
I'm just seeing this reply today, please excuse the late reply.
I tried your suggestion, it I do get results back, but I get back a list of
Users when I instead am trying to get back a list of Posts.
Is it not possible to arbitrarily sort by either side of the join in solr?
> Have
Have your tried using the join in the fq instead of the q?
Like this (assuming user_id_i is a field in the post document type and
self_id_i a field in the user document type):
q=posts_text:"hello"&fq={!join from=self_id_i
to=user_id_i}is_active_boolean:true
In this example the fq produces a docset
Does anyone have any idea on this issue?
On Tue, Oct 25, 2011 at 11:40 AM, Jason Toy wrote:
> Hi Yonik,
>
> Without a Join I would normally query user docs with:
> q=data_text:"test"&fq=is_active_boolean:true
>
> With joining users with posts, I get no no results:
> q={!join from=self_id_i
> to=
Hi Yonik,
Without a Join I would normally query user docs with:
q=data_text:"test"&fq=is_active_boolean:true
With joining users with posts, I get no no results:
q={!join from=self_id_i
to=user_id_i}data_text:"test"&fq=is_active_boolean:true&fq=posts_text:"hello"
I am able to use this query, bu
Can you give an example of the request (URL) you are sending to Solr?
-Yonik
http://www.lucidimagination.com
On Mon, Oct 24, 2011 at 3:31 PM, Jason Toy wrote:
> I have 2 types of docs, users and posts.
> I want to view all the docs that belong to certain users by joining posts
> and users toge
Thanks for the advice. Glad you like the site! Yes, we are using the
new multi-select support to do this. At first, we wrote our own client-
side solution to allow for multi-select which was super complex but
moved to the built-in solr support as soon as we found it. Excellent
feature!
-Na
Nasseam Elkarra schrieb:
I am storing items in an index. Each item has a comma separated list
of related items. Is it possible to bring back an item and all of its
related items in one query? If so how and how would you distinguish
between which one is the main item and which are the related.
On Fri, Jun 12, 2009 at 6:43 PM, Nasseam Elkarra wrote:
> I am storing items in an index. Each item has a comma separated list of
> related items. Is it possible to bring back an item and all of its related
> items in one query? If so how and how would you distinguish between which
> one is the mai
Hi Nasseam,
You might be able to do this with the MoreLikeThis capability, but I'm
not 100% sure. It would likely take some custom work as well.
-Grant
On Jun 12, 2009, at 6:43 PM, Nasseam Elkarra wrote:
Hello,
I am storing items in an index. Each item has a comma separated list
of rel
34 matches
Mail list logo
