[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling
[ https://issues.apache.org/jira/browse/SOLR-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576201#comment-16576201 ] boxbe-notificati...@boxbe.com commented on SOLR-8297: - Hello boxbe-notificati...@boxbe.com (JIRA), You will not receive any more courtesy notices from our members for two days. Messages you have sent will remain in a lower priority mailbox for our member to review at their leisure. Future messages will be more likely to be viewed if you are on our member's priority Guest List. Thank you, jyotitiwari...@gmail.com Powered by Boxbe -- "End Email Overload" Visit http://www.boxbe.com/how-it-works?tc_serial=42006490047_rand=1573718456_source=stf_medium=email_campaign=CN_MNC_content=002 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Allow join query over 2 sharded collections: enhance functionality and > exception handling > - > > Key: SOLR-8297 > URL: https://issues.apache.org/jira/browse/SOLR-8297 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.3 >Reporter: Paul Blanchaert >Priority: Major > Attachments: SOLR-8297.patch, SOLR-8297_Latest.patch > > > h2. Proposal > h3. General Idea > Approach [~shikhasomani]'s range check algorithm to the most cases > h3. Join behavior depending on router types of joined collections > || to\\from ||CompositeId||Implicit|| > ||CompositeId| shard range check, see table below | allow | > ||Implicit| allow | shard to shard | > h3. CompositeId to CompositeId join behaviour for certain number of shards > > || to\\from ||single||>1|| > ||single| allow (as is) | allow (range check) | > ||>1| allow (as is) | per shard range check | > h3. Rules from the tables above > * joining from/to CompositeId and Implicit is blindly allowed, it pick ups > any collocated replica, because users who do that probably understand what > they do. > * when both sides are Implicit let's join shards by name. ie if request hits > collectionTO_shardY_replica2 at a node, the collocated > collectionFROM_shardY_replica* is expected. > * when both sides are CompositeId > ** from single shard to single shard - nobrainer, just needs collocated > replica; > ** from multiple shards to single shard - all "from" shards (any it's > replicas) are picked for joining > ** from single shard to multiple shards - existing SOLR-4905 functionality > ** from multiple to multiple - generic range check algorithm > ### check that fromField and toField are router.keys in these collections > ### take shard range for the current "to" collection replica (keep in mind > that request is distributed across "to" collection shards) > ### enumerate "from" collection shrads, find their subset which covers "to" > shard range (this allows to handle any number of shards at both sides) > ### pickup collocated replicas of these "from" shard subset > h3. Caveat > this is quite sensitive to shard allocation (and/or replica placement) ie > failed "from" replica cannot be collocated with the required "to" shard. > h2. Initial Description > Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail > Khludnev. > A) exception handling: > The exception "SolrCloud join: multiple shards not yet supported" thrown in > the function findLocalReplicaForFromIndex of JoinQParserPlugin is not > triggered correctly: In my use-case, I've a join on a facet.query and when my > results are only found in 1 shard and the facet.query with the join is > querying the last replica of the last slice, then the exception is not thrown. > I believe it's better to verify the nr of slices when we want to verify the > "multiple shards not yet supported" exception (so exception is thrown when > zkController.getClusterState().getSlices(fromIndex).size()>1). > B) functional enhancement: > I would expect that there is no problem to perform a cross-core join over > sharded collections when the following conditions are met: > 1) both collections are sharded with the same replicationFactor and numShards > 2) router.field of the collections is set to the same "key-field" (collection > of "fromindex" has router.field = "from" field and collection joined to has > router.field = "to" field) > The router.field setup ensures that d
[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling
[ https://issues.apache.org/jira/browse/SOLR-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576178#comment-16576178 ] boxbe-notificati...@boxbe.com commented on SOLR-8297: - Hello boxbe-notificati...@boxbe.com (JIRA), Your message about "[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling" has been waitlisted. Please add yourself to my Boxbe Guest List so your messages will go to my Inbox. Click the link below to be added: https://www.boxbe.com/crs?tc_serial=42005862190_rand=1440666013_source=stf_medium=email_campaign=CN_STDW_content=002 Thank you, jyotitiwari...@gmail.com Powered by Boxbe -- "End Email Overload" Visit http://www.boxbe.com/how-it-works?tc_serial=42005862190_rand=1440666013_source=stf_medium=email_campaign=CN_STDW_content=002 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Allow join query over 2 sharded collections: enhance functionality and > exception handling > - > > Key: SOLR-8297 > URL: https://issues.apache.org/jira/browse/SOLR-8297 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.3 >Reporter: Paul Blanchaert >Priority: Major > Attachments: SOLR-8297.patch, SOLR-8297_Latest.patch > > > h2. Proposal > h3. General Idea > Approach [~shikhasomani]'s range check algorithm to the most cases > h3. Join behavior depending on router types of joined collections > || to\\from ||CompositeId||Implicit|| > ||CompositeId| shard range check, see table below | allow | > ||Implicit| allow | shard to shard | > h3. CompositeId to CompositeId join behaviour for certain number of shards > > || to\\from ||single||>1|| > ||single| allow (as is) | allow (range check) | > ||>1| allow (as is) | per shard range check | > h3. Rules from the tables above > * joining from/to CompositeId and Implicit is blindly allowed, it pick ups > any collocated replica, because users who do that probably understand what > they do. > * when both sides are Implicit let's join shards by name. ie if request hits > collectionTO_shardY_replica2 at a node, the collocated > collectionFROM_shardY_replica* is expected. > * when both sides are CompositeId > ** from single shard to single shard - nobrainer, just needs collocated > replica; > ** from multiple shards to single shard - all "from" shards (any it's > replicas) are picked for joining > ** from single shard to multiple shards - existing SOLR-4905 functionality > ** from multiple to multiple - generic range check algorithm > ### check that fromField and toField are router.keys in these collections > ### take shard range for the current "to" collection replica (keep in mind > that request is distributed across "to" collection shards) > ### enumerate "from" collection shrads, find their subset which covers "to" > shard range (this allows to handle any number of shards at both sides) > ### pickup collocated replicas of these "from" shard subset > h3. Caveat > this is quite sensitive to shard allocation (and/or replica placement) ie > failed "from" replica cannot be collocated with the required "to" shard. > h2. Initial Description > Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail > Khludnev. > A) exception handling: > The exception "SolrCloud join: multiple shards not yet supported" thrown in > the function findLocalReplicaForFromIndex of JoinQParserPlugin is not > triggered correctly: In my use-case, I've a join on a facet.query and when my > results are only found in 1 shard and the facet.query with the join is > querying the last replica of the last slice, then the exception is not thrown. > I believe it's better to verify the nr of slices when we want to verify the > "multiple shards not yet supported" exception (so exception is thrown when > zkController.getClusterState().getSlices(fromIndex).size()>1). > B) functional enhancement: > I would expect that there is no problem to perform a cross-core join over > sharded collections when the following conditions are met: > 1) both collections are sharded with the same replicationFactor and numShards > 2) router.field of the collections is set to the same "key-field" (collection > of "fromindex" has router.field = "f
[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling
[ https://issues.apache.org/jira/browse/SOLR-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576151#comment-16576151 ] boxbe-notificati...@boxbe.com commented on SOLR-8297: - Hello boxbe-notificati...@boxbe.com (JIRA), Your message "[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling" to me was waitlisted. Get your message to my inbox by clicking the following link. https://www.boxbe.com/crs?tc_serial=42005237516_rand=1844341005_source=stf_medium=email_campaign=CN_STDW_content=003 Thank you, jyotitiwari...@gmail.com P.S. ...you'll only have to do this once. Future emails will appear immediately in my inbox. Supercharge your Email Visit http://www.boxbe.com/how-it-works?tc_serial=42005237516_rand=1844341005_source=stf_medium=email_campaign=CN_STDW_content=003 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Allow join query over 2 sharded collections: enhance functionality and > exception handling > - > > Key: SOLR-8297 > URL: https://issues.apache.org/jira/browse/SOLR-8297 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.3 >Reporter: Paul Blanchaert >Priority: Major > Attachments: SOLR-8297.patch, SOLR-8297_Latest.patch > > > h2. Proposal > h3. General Idea > Approach [~shikhasomani]'s range check algorithm to the most cases > h3. Join behavior depending on router types of joined collections > || to\\from ||CompositeId||Implicit|| > ||CompositeId| shard range check, see table below | allow | > ||Implicit| allow | shard to shard | > h3. CompositeId to CompositeId join behaviour for certain number of shards > > || to\\from ||single||>1|| > ||single| allow (as is) | allow (range check) | > ||>1| allow (as is) | per shard range check | > h3. Rules from the tables above > * joining from/to CompositeId and Implicit is blindly allowed, it pick ups > any collocated replica, because users who do that probably understand what > they do. > * when both sides are Implicit let's join shards by name. ie if request hits > collectionTO_shardY_replica2 at a node, the collocated > collectionFROM_shardY_replica* is expected. > * when both sides are CompositeId > ** from single shard to single shard - nobrainer, just needs collocated > replica; > ** from multiple shards to single shard - all "from" shards (any it's > replicas) are picked for joining > ** from single shard to multiple shards - existing SOLR-4905 functionality > ** from multiple to multiple - generic range check algorithm > ### check that fromField and toField are router.keys in these collections > ### take shard range for the current "to" collection replica (keep in mind > that request is distributed across "to" collection shards) > ### enumerate "from" collection shrads, find their subset which covers "to" > shard range (this allows to handle any number of shards at both sides) > ### pickup collocated replicas of these "from" shard subset > h3. Caveat > this is quite sensitive to shard allocation (and/or replica placement) ie > failed "from" replica cannot be collocated with the required "to" shard. > h2. Initial Description > Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail > Khludnev. > A) exception handling: > The exception "SolrCloud join: multiple shards not yet supported" thrown in > the function findLocalReplicaForFromIndex of JoinQParserPlugin is not > triggered correctly: In my use-case, I've a join on a facet.query and when my > results are only found in 1 shard and the facet.query with the join is > querying the last replica of the last slice, then the exception is not thrown. > I believe it's better to verify the nr of slices when we want to verify the > "multiple shards not yet supported" exception (so exception is thrown when > zkController.getClusterState().getSlices(fromIndex).size()>1). > B) functional enhancement: > I would expect that there is no problem to perform a cross-core join over > sharded collections when the following conditions are met: > 1) both collections are sharded with the same replicationFactor and numShards > 2) router.field of the collections is set to the same "key-field" (collection > of "fromindex" has router.f
[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling
[ https://issues.apache.org/jira/browse/SOLR-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576128#comment-16576128 ] boxbe-notificati...@boxbe.com commented on SOLR-8297: - Hello boxbe-notificati...@boxbe.com (JIRA), Your message "[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling" to me was waitlisted. Get your message to my inbox by clicking the following link. https://www.boxbe.com/crs?tc_serial=42004653105_rand=1269770423_source=stf_medium=email_campaign=CN_STDW_content=003 Thank you, jyotitiwari...@gmail.com P.S. ...you'll only have to do this once. Future emails will appear immediately in my inbox. Supercharge your Email Visit http://www.boxbe.com/how-it-works?tc_serial=42004653105_rand=1269770423_source=stf_medium=email_campaign=CN_STDW_content=003 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Allow join query over 2 sharded collections: enhance functionality and > exception handling > - > > Key: SOLR-8297 > URL: https://issues.apache.org/jira/browse/SOLR-8297 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.3 >Reporter: Paul Blanchaert >Priority: Major > Attachments: SOLR-8297.patch, SOLR-8297_Latest.patch > > > h2. Proposal > h3. General Idea > Approach [~shikhasomani]'s range check algorithm to the most cases > h3. Join behavior depending on router types of joined collections > || to\\from ||CompositeId||Implicit|| > ||CompositeId| shard range check, see table below | allow | > ||Implicit| allow | shard to shard | > h3. CompositeId to CompositeId join behaviour for certain number of shards > > || to\\from ||single||>1|| > ||single| allow (as is) | allow (range check) | > ||>1| allow (as is) | per shard range check | > h3. Rules from the tables above > * joining from/to CompositeId and Implicit is blindly allowed, it pick ups > any collocated replica, because users who do that probably understand what > they do. > * when both sides are Implicit let's join shards by name. ie if request hits > collectionTO_shardY_replica2 at a node, the collocated > collectionFROM_shardY_replica* is expected. > * when both sides are CompositeId > ** from single shard to single shard - nobrainer, just needs collocated > replica; > ** from multiple shards to single shard - all "from" shards (any it's > replicas) are picked for joining > ** from single shard to multiple shards - existing SOLR-4905 functionality > ** from multiple to multiple - generic range check algorithm > ### check that fromField and toField are router.keys in these collections > ### take shard range for the current "to" collection replica (keep in mind > that request is distributed across "to" collection shards) > ### enumerate "from" collection shrads, find their subset which covers "to" > shard range (this allows to handle any number of shards at both sides) > ### pickup collocated replicas of these "from" shard subset > h3. Caveat > this is quite sensitive to shard allocation (and/or replica placement) ie > failed "from" replica cannot be collocated with the required "to" shard. > h2. Initial Description > Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail > Khludnev. > A) exception handling: > The exception "SolrCloud join: multiple shards not yet supported" thrown in > the function findLocalReplicaForFromIndex of JoinQParserPlugin is not > triggered correctly: In my use-case, I've a join on a facet.query and when my > results are only found in 1 shard and the facet.query with the join is > querying the last replica of the last slice, then the exception is not thrown. > I believe it's better to verify the nr of slices when we want to verify the > "multiple shards not yet supported" exception (so exception is thrown when > zkController.getClusterState().getSlices(fromIndex).size()>1). > B) functional enhancement: > I would expect that there is no problem to perform a cross-core join over > sharded collections when the following conditions are met: > 1) both collections are sharded with the same replicationFactor and numShards > 2) router.field of the collections is set to the same "key-field" (collection > of "fromindex" has router.f
[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling
[ https://issues.apache.org/jira/browse/SOLR-8297?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16576115#comment-16576115 ] boxbe-notificati...@boxbe.com commented on SOLR-8297: - Hello Mikhail Khludnev (JIRA), Your message "[jira] [Commented] (SOLR-8297) Allow join query over 2 sharded collections: enhance functionality and exception handling" to me was waitlisted. Get your message to my inbox by clicking the following link. https://www.boxbe.com/crs?tc_serial=42004022853_rand=760964287_source=stf_medium=email_campaign=CN_STDW_content=003 Thank you, jyotitiwari...@gmail.com P.S. ...you'll only have to do this once. Future emails will appear immediately in my inbox. Supercharge your Email Visit http://www.boxbe.com/how-it-works?tc_serial=42004022853_rand=760964287_source=stf_medium=email_campaign=CN_STDW_content=003 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Allow join query over 2 sharded collections: enhance functionality and > exception handling > - > > Key: SOLR-8297 > URL: https://issues.apache.org/jira/browse/SOLR-8297 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 5.3 >Reporter: Paul Blanchaert >Priority: Major > Attachments: SOLR-8297.patch, SOLR-8297_Latest.patch > > > h2. Proposal > h3. General Idea > Approach [~shikhasomani]'s range check algorithm to the most cases > h3. Join behavior depending on router types of joined collections > || to\\from ||CompositeId||Implicit|| > ||CompositeId| shard range check, see table below | allow | > ||Implicit| allow | shard to shard | > h3. CompositeId to CompositeId join behaviour for certain number of shards > > || to\\from ||single||>1|| > ||single| allow (as is) | allow (range check) | > ||>1| allow (as is) | per shard range check | > h3. Rules from the tables above > * joining from/to CompositeId and Implicit is blindly allowed, it pick ups > any collocated replica, because users who do that probably understand what > they do. > * when both sides are Implicit let's join shards by name. ie if request hits > collectionTO_shardY_replica2 at a node, the collocated > collectionFROM_shardY_replica* is expected. > * when both sides are CompositeId > ** from single shard to single shard - nobrainer, just needs collocated > replica; > ** from multiple shards to single shard - all "from" shards (any it's > replicas) are picked for joining > ** from single shard to multiple shards - existing SOLR-4905 functionality > ** from multiple to multiple - generic range check algorithm > ### check that fromField and toField are router.keys in these collections > ### take shard range for the current "to" collection replica (keep in mind > that request is distributed across "to" collection shards) > ### enumerate "from" collection shrads, find their subset which covers "to" > shard range (this allows to handle any number of shards at both sides) > ### pickup collocated replicas of these "from" shard subset > h3. Caveat > this is quite sensitive to shard allocation (and/or replica placement) ie > failed "from" replica cannot be collocated with the required "to" shard. > h2. Initial Description > Enhancement based on SOLR-4905. New Jira issue raised as suggested by Mikhail > Khludnev. > A) exception handling: > The exception "SolrCloud join: multiple shards not yet supported" thrown in > the function findLocalReplicaForFromIndex of JoinQParserPlugin is not > triggered correctly: In my use-case, I've a join on a facet.query and when my > results are only found in 1 shard and the facet.query with the join is > querying the last replica of the last slice, then the exception is not thrown. > I believe it's better to verify the nr of slices when we want to verify the > "multiple shards not yet supported" exception (so exception is thrown when > zkController.getClusterState().getSlices(fromIndex).size()>1). > B) functional enhancement: > I would expect that there is no problem to perform a cross-core join over > sharded collections when the following conditions are met: > 1) both collections are sharded with the same replicationFactor and numShards > 2) router.field of the collections is set to the same "key-field" (collection > of "fromindex" has router.field = "from" field and collection joined to has > router.field = "to" field) > The router.field setup ensures that documents with the same "key-field" are > routed to the same node. > So the combination based on the "key-field" should always be available within > the same node. > From a user perspective, I believe these assumptions seem to be a "normal" > use-case
[jira] [Commented] (LUCENE-3759) Support joining in a distributed environment.
[ https://issues.apache.org/jira/browse/LUCENE-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571813#comment-16571813 ] boxbe-notificati...@boxbe.com commented on LUCENE-3759: --- Hello Steve Rowe (JIRA), Your message about "[jira] Steve Rowe mentioned you on LUCENE-3759 (JIRA) (JIRA)" has been waitlisted. Please add yourself to my Boxbe Guest List so your messages will go to my Inbox. Click the link below to be added: https://www.boxbe.com/crs?tc_serial=41904072875_rand=1482900733_source=stf_medium=email_campaign=CN_STDW_content=002 Thank you, jyotitiwari...@gmail.com Powered by Boxbe -- "End Email Overload" Visit http://www.boxbe.com/how-it-works?tc_serial=41904072875_rand=1482900733_source=stf_medium=email_campaign=CN_STDW_content=002 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Support joining in a distributed environment. > - > > Key: LUCENE-3759 > URL: https://issues.apache.org/jira/browse/LUCENE-3759 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/join >Reporter: Martijn van Groningen >Priority: Major > > Add two more methods in JoinUtil to support joining in a distributed manner. > * Method to retrieve all from values. > * Method to create a TermsQuery based on a set of from terms. > With these two methods distributed joining can be supported following these > steps: > # Retrieve from values from each shard > # Merge the retrieved from values. > # Create a TermsQuery based on the merged from terms and send this query to > all shards. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3759) Support joining in a distributed environment.
[ https://issues.apache.org/jira/browse/LUCENE-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571779#comment-16571779 ] boxbe-notificati...@boxbe.com commented on LUCENE-3759: --- Hello boxbe-notificati...@boxbe.com (JIRA), Your message about "[jira] [Commented] (LUCENE-3759) Support joining in a distributed environment." has been waitlisted. Please add yourself to my Boxbe Guest List so your messages will go to my Inbox. Click the link below to be added: https://www.boxbe.com/crs?tc_serial=41903616834_rand=1951428269_source=stf_medium=email_campaign=CN_STDW_content=002 Thank you, jyotitiwari...@gmail.com Powered by Boxbe -- "End Email Overload" Visit http://www.boxbe.com/how-it-works?tc_serial=41903616834_rand=1951428269_source=stf_medium=email_campaign=CN_STDW_content=002 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Support joining in a distributed environment. > - > > Key: LUCENE-3759 > URL: https://issues.apache.org/jira/browse/LUCENE-3759 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/join >Reporter: Martijn van Groningen >Priority: Major > > Add two more methods in JoinUtil to support joining in a distributed manner. > * Method to retrieve all from values. > * Method to create a TermsQuery based on a set of from terms. > With these two methods distributed joining can be supported following these > steps: > # Retrieve from values from each shard > # Merge the retrieved from values. > # Create a TermsQuery based on the merged from terms and send this query to > all shards. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3759) Support joining in a distributed environment.
[ https://issues.apache.org/jira/browse/LUCENE-3759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16571756#comment-16571756 ] boxbe-notificati...@boxbe.com commented on LUCENE-3759: --- Hello Erick Erickson (JIRA), Your message about "[jira] [Commented] (LUCENE-3759) Support joining in a distributed environment." has been waitlisted. Please add yourself to my Boxbe Guest List so your messages will go to my Inbox. Click the link below to be added: https://www.boxbe.com/crs?tc_serial=41903085343_rand=1938794750_source=stf_medium=email_campaign=CN_STDW_content=002 Thank you, jyotitiwari...@gmail.com Powered by Boxbe -- "End Email Overload" Visit http://www.boxbe.com/how-it-works?tc_serial=41903085343_rand=1938794750_source=stf_medium=email_campaign=CN_STDW_content=002 Boxbe, Inc. | 65 Broadway, Suite 601 | New York, NY 10006 Privacy Policy: http://www.boxbe.com/privacy | Unsubscribe: http://www.boxbe.com/unsubscribe > Support joining in a distributed environment. > - > > Key: LUCENE-3759 > URL: https://issues.apache.org/jira/browse/LUCENE-3759 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/join >Reporter: Martijn van Groningen >Priority: Major > > Add two more methods in JoinUtil to support joining in a distributed manner. > * Method to retrieve all from values. > * Method to create a TermsQuery based on a set of from terms. > With these two methods distributed joining can be supported following these > steps: > # Retrieve from values from each shard > # Merge the retrieved from values. > # Create a TermsQuery based on the merged from terms and send this query to > all shards. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
