It added complexity, for Lucene to track the app-provided ID. And, it's something you can easily add back on top of the new API, if necessary.
But, maintaining multiple snapshots is certainly still allowed: multiple snapshots referencing the same IndexCommit is fine. There is a ref count incremented each time (inside SDP), so as long as you match each snapshot with a call to release(IndexCommit) it will all work out, even when snapshots share the same IndexCommit; you don't need to do your own outside reference counting. The API is marked as experimental so it's subject to change suddenly as we iterate... Mike McCandless http://blog.mikemccandless.com On Fri, Jan 24, 2014 at 2:47 PM, Vitaly Funstein <vfunst...@gmail.com> wrote: > I see that SnapshotDeletionPolicy no longer supports snapshotting by an > app-supplied string id, as of Lucene 4.4. However, my use case relies on > the policy's ability to maintain multiple snapshots simultaneously to > provide index versioning semantics, of sorts. What is the new recommended > way of doing this? > > I see that release() now accepts IndexCommit; does this mean that I am now > responsible for maintaining a map of string ids to IndexCommit instances > myself? What about the situation when multiple snapshots refer to the same > commit point - I need to do reference counting and make sure I don't > release the commit until the snapshot reference count reaches 0, similar to > how release() was implemented before this change? > > Not sure what the rationale for this was, but it seems like the change > makes use of this API harder than before... unless I'm totally missing > something obvious. --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
