Re: Oak Indexing. Was Re: Property index replacement / evolution

Hi, On 11 August 2016 at 13:03, Chetan Mehrotra wrote: > On Thu, Aug 11, 2016 at 5:19 PM, Ian Boston wrote: > > correct. > > Documents are shared by ID so all updates hit the same shard. > > That may result in network traffic if the shard is not

Re: Oak Indexing. Was Re: Property index replacement / evolution

On 11 August 2016 at 11:10, Chetan Mehrotra wrote: > On Thu, Aug 11, 2016 at 3:03 PM, Ian Boston wrote: > > Both Solr Cloud and ES address this by sharding and > > replicating the indexes, so that all commits are soft, instant and real > > time. That

Re: Oak Indexing. Was Re: Property index replacement / evolution

On Thu, Aug 11, 2016 at 3:03 PM, Ian Boston wrote: > Both Solr Cloud and ES address this by sharding and > replicating the indexes, so that all commits are soft, instant and real > time. That introduces problems. ... > Both Solr Cloud and ES address this by sharding and >

Re: Oak Indexing. Was Re: Property index replacement / evolution

Hi, There is no need to have several different plugins to deal with the standalone, small scale cluster, large scale cluster deployment. It might be desirable for some reason, but it's not necessary. I have pushed the code I was working before I got distracted it to a GitHub repo. [1] is where

Re: Oak Indexing. Was Re: Property index replacement / evolution

Couple of points around the motivation, target usecase around Hybrid Indexing and Oak indexing in general. Based on my understanding of various deployments. Any application based on Oak has 2 type of query requirements QR1. Application Query - These mostly involve some property restrictions and