That's an interesting point ... I still think we should use IDs though, because the application that uses this (like me :)) may want to persist the snapshots used elsewhere, in case the JVM crashes. That's another weak point of SDP today - if the JVM dies, your snapshot might get deleted, which depending on why you took it may not be what you want. So, what I've implemented actually allows init'ing SDP w/ existing snapshots information (a Map from String [id] to String [segmentsName]), so that when you open IndexWriter, the wrapped DP won't delete those snapshots for you (onInit will ensure that).
Another thing I've run into is several processes that take a snapshot over the same commit. The IDs allow me to safely release only one snapshot, but the commit will remain because it's snapshotted by another process. While it's still supported if release() receives IndexCommit (I can decRef that IC or something), it will be less clear? So ... while both those scenarios are still supported if we don't use IDs, I think IDs will be easier for apps to integrate w/ that feature. Sometimes it's useful why a snapshot is held, and if you use a meaningful ID, like "copyIndex[timestamp]", one can determine that snapshot is not needed anymore. In fact, some comments I've received about using Id were that Ids are too simple, and perhaps a more complex object can be associated w/ a snapshot. But for now I think Id is enough, until proven otherwise. What do you think? Shai On Tue, Apr 27, 2010 at 6:04 PM, Michael McCandless < [email protected]> wrote: > On Tue, Apr 27, 2010 at 11:03 AM, Earwin Burrfoot <[email protected]> > wrote: > > I think we should enhance SDP. > > I also think we shouldn't do IDs. snapshot() returns IndexCommitPoint, > > release() should get a parameter accepting IndexCommitPoint, that's > > all. > > +1 > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
