Then are there some other alternative so that we can achieve the goal. As querying with this way of set of foreign id is really going to make the query very large and the response is also awaited for long(previously tested with the standalone Solr core with Master Slave Architecture).
Thanks! On Mon, Jun 9, 2014 at 8:42 PM, Erick Erickson <erickerick...@gmail.com> wrote: > My first answer is "don't do it that way" :). > > Solr works best with flattened (de-normlized) data. If at all > possible, you _really_ would be better off combining the two > collections and flattening the data even though there would be more > data. > > Whenever I see a question like this, I wonder if you're trying to use > Solr like a DB, in this case with "collections" substituting for > "tables", and this is almost always a mistake. > > If you really must do this, consider cross-core joins if at all > possible, but I don't think this is supported yet for distributed > setups. > > Best, > Erick > > On Mon, Jun 9, 2014 at 7:32 AM, Vineet Mishra <clearmido...@gmail.com> > wrote: > > Hi All, > > > > I was curious to know how multiple Collection communication be achieved? > If > > yes then by what means. > > > > The use case says, having multiple collection I need to query the first > > collection and get the unique ids from first collection to query the > second > > one(Foreign Key Relation). Now if the no. of terms to be passed to second > > collection is relatively small then its fine otherwise the problem arise, > > as adding them to the query is little time consuming in sense of building > > the query, querying to solr and waiting for the result to respond back. > > > > So the query would look something like - > > > > http://localhost:7070/solr/mycollection/select?q= > > < > http://localhost:7070/solr/recollection/select?q=*:*&fl=id&sort=id_S%20desc > >ID:( > > 1 OR 2 OR ... OR 100000)&fl=* > > > > So for the above form of query where the query terms are expanding > > vigorously I was looking out for some solution where the collections can > > internally resolve the query and fetch the resultant output. > > > > Thanks! >
