What do you mean by "stable"? and why would you want to refresh your reader only once a day?
It sounds like what you are looking for is some sort of a snaphotting mechanism? if so, maybe try to model your data where you have a document / type that has the data in its stable form and update it periodically based on your business logic? Elasticsearch doesn't support what you describe going all the way to a specific commit, but the scan/scroll search type is pretty much what you describe: http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/search-request-search-type.html#scan I think having this implemented on the Lucene commit level is going to be tricky if not impossible due to the distributed nature of ES (every shard on every node is practically a different Lucene index) -- Itamar Syn-Hershko http://code972.com | @synhershko <https://twitter.com/synhershko> Freelance Developer & Consultant Author of RavenDB in Action <http://manning.com/synhershko/> On Tue, Apr 8, 2014 at 12:45 PM, David Causse <[email protected]> wrote: > Hi, > > I'm evaluating ES features by reading the doc. Here is the missing usecase > I was not able to find in the documentation. > > I want to perform query in an index from 2 differents applications. > > One application needs NRT view of the index. And another needs a more > stable view of the data (refreshed every day or hour, it depends on > application needs). > > With raw Lucene it's quite easy to implement such feature : > > - Keep one IndexReader open for the stable view + NRT : drawback is > that I loose my IndexReader if the application restarts > - Use IndexCommit and IndexDeletionPolicy for the stable IndexReader, > it supports app restart. > > Does ES supports these lucene features : keep a commit point, open a > reader on that particular commit (and delete the index commit when it's no > more needed)? > > As the base feature is part of Lucene API would it be hard to implement > such feature into ES? (I suspect scroll api to already keep an opened > IndexReader under the hood, isn't it possible to generalize it to the query > API?) > > Thanks. > > -- > You received this message because you are subscribed to the Google Groups > "elasticsearch" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elasticsearch/4b082651-51e6-499c-8882-44398c857dc8%40googlegroups.com<https://groups.google.com/d/msgid/elasticsearch/4b082651-51e6-499c-8882-44398c857dc8%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "elasticsearch" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elasticsearch/CAHTr4ZvKyNH%2BEk28N1-CpqaGuST7TA7YOA44_kq%3D8B9bMhT3tg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
