I was thinking of something really simple:
- "wait for refresh" call registers a listener
- When the next index refresh finishes, notify (and deregister) all
registered listeners -> each listener sends an "OK" response
No need to track documents, just keep a set of listeners (maybe you need one
set per index or per shard?)
I thought all the request handling was asynchronous anyway, so the callback
for the HTTP response wouldn't be a problem?
To give a little more detail on my use case:
I'm not really doing simple parent/child relationships, it's more like:
A: Index a set of documents
B: Index a related set of documents into another index
I don't want any of the docs from set B to show up in search results until I
am sure that all the docs from set A are visible to searching as well.
There may not be explicit parent-child relationships to follow at the
document level. All retrieval is done through search queries.
On Thu, Jun 9, 2011 at 1:25 PM, Shay Banon email@example.com:
Callbacks are problematic, especially over HTTP, so its not really an
option because of its complexity. I think that most times you can really
work around it, use versions, or we can work on other features to enable it.
For example, we can easily provide a full realtime "doc exists" API (with
realtime version response).
On Thursday, June 9, 2011 at 11:22 PM, Karussell wrote:
On Jun 9, 9:21 pm, Shay Banon shay.ba...@elasticsearch.com wrote:
No, there isn't one, and its problematic to provide? It means that
elasticsearch will need to keep track of the indexed documents, so you will
be able to tell if it happened after them. Parent child visibility can be
ensure by indexing the parent doc before the child doc for example.
E.g. FAST ESP provides listeners for this purposes and especially with
the NRT feature one now cannot give a guarantuee when a doc gets
It means that elasticsearch will need to keep track of the indexed
maybe only for a subset? or one can mark only one document as a