On Mon, Dec 1, 2014 at 8:23 PM, Mark Kerzner <[email protected]> wrote: > Aaron, > > I am really grateful for such a complete answer. As an aside, is there a > book or a document where this kind of reference is collected? Surely I will > have my own notes.
These explanations are [mostly] covered throughout the API documentation[1] but unfortunately, no, it's not nicely collected in one spot - I've just added a ticket for that[2]. > For my future purpose - to give the user the latest updates that have made > it into the index yet - it seems that way 2. is the closest. To give the user the most recent data 1 is the way to go. The tradeoff being that the thrift mutate calls provide instant access at the tradeoff of [relatively] lower overall indexing throughput. 2 is slightly slower [but configurable as Aaron mentioned] access to new data, but has the advantage of a higher throughput. > Do I > understand correctly that Blur will keep indexing for 5 seconds > (configurable), while the user, who searches against the index, will not > see the new results? Yes, that's correct. > However, there is a queue in front of the index that > one can query separately? The queued docs are currently not accessible at all. In any of these indexing approaches, Blur [currently] doesn't support uncommitted results to be returned. Probably most of us just haven't come across a scenario where that behavior would be considered a "Good Thing" :) Thanks, --tim
