This doesn't appear to be being actively pursued, so it's anybody's guess.
Depending on your use-case, the streaming capabilities may be an
OOB solution.
Best,
Erick
On Wed, Feb 6, 2019 at 1:22 AM mganeshs wrote:
>
> All,
>
> Any idea, whether this will be taken care or addressed in near
All,
Any idea, whether this will be taken care or addressed in near future ?
https://issues.apache.org/jira/browse/SOLR-8297
Regards,
--
Sent from: http://lucene.472066.n3.nabble.com/Solr-User-f472068.html
ture will be in place ?
>
> Regards,
>
>
>
> --
> View this message in context: http://lucene.472066.n3.
> nabble.com/Allow-Join-over-two-sharded-collection-tp4343443p4344098.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
will be in place ?
Regards,
--
View this message in context:
http://lucene.472066.n3.nabble.com/Allow-Join-over-two-sharded-collection-tp4343443p4344098.html
Sent from the Solr - User mailing list archive at Nabble.com.
ery month 1M of documents.
>>>> The reason why don't want to for time based implicit routing is that,
>>> all
>>>> documents will end up with recent shard and so indexing will be heavy
>>> for
>>>> the new shard, where as older shards will be
default sharding, then load for indexing is distributed
>> across
>> > all the shards. That's the reason we would like to stick to default
>> > sharding. But Join is the issue over here when default sharding is used
>> :-(
>> >
>> >
>> >
>> > --
>> > View this message in context: http://lucene.472066.n3.nabble
>> .com/Allow-Join-over-two-sharded-collection-tp4343443p4343803.html
>> > Sent from the Solr - User mailing list archive at Nabble.com.
>>
>
>
> the new shard, where as older shards will be used just for query purpose.
> > If we have default sharding, then load for indexing is distributed across
> > all the shards. That's the reason we would like to stick to default
> > sharding. But Join is the issue over here when de
e would like to stick to default
> sharding. But Join is the issue over here when default sharding is used :-(
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Allow-Join-over-two-sharded-collection-tp4343443p4343803.html
> Sent from the Solr - User mailing list archive at Nabble.com.
:
http://lucene.472066.n3.nabble.com/Allow-Join-over-two-sharded-collection-tp4343443p4343803.html
Sent from the Solr - User mailing list archive at Nabble.com.
> >
> > Regards,
> >
> >
> >
> > --
> > View this message in context: http://lucene.472066.n3.
> > nabble.com/Allow-Join-over-two-sharded-collection-tp4343443.html
> > Sent from the Solr - User mailing list archive at Nabble.com.
> >
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
8297
>
> One of the comments says by SOLR 7.0. Can we expect that by 7.0 ?
>
> Regards,
>
>
>
> --
> View this message in context: http://lucene.472066.n3.
> nabble.com/Allow-Join-over-two-sharded-collection-tp4343443.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
--
Sincerely yours
Mikhail Khludnev
every change in ACL or its permission we don't want to
> re-index the real document as well.
>
> Do you think is there any better alternative ? or the way we have kept ACLs
> are wrong ?
>
> Regards,
>
>
>
> --
> View this message in context: http://lucene.472066.n3.
>
are wrong ?
Regards,
--
View this message in context:
http://lucene.472066.n3.nabble.com/Allow-Join-over-two-sharded-collection-tp4343443p4343582.html
Sent from the Solr - User mailing list archive at Nabble.com.
ents says by SOLR 7.0. Can we expect that by 7.0 ?
>
> Regards,
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/Allow-Join-over-two-sharded-collection-tp4343443.html
> Sent from the Solr - User mailing list archive at Nabble.com.
066.n3.nabble.com/Allow-Join-over-two-sharded-collection-tp4343443.html
Sent from the Solr - User mailing list archive at Nabble.com.
15 matches
Mail list logo
