Lucene is able to do this, if you make a custom DeletionPolicy (which controls when commit points are deleted).
By default Lucene only saves the most recent commit (KeepOnlyLastCommitDeletionPolicy), but if your policy keeps more around, then you can open an IndexReader or IndexWriter on any IndexCommit. Any changes (including optimize, and even opening a new IW with create=true) are safe within a commit; Lucene is fully transactional. For example, I use this for benchmarking: I save 4 commit points in a single index. First is a multi-segment index, second is the same index with 5% deletions, third is an optimized index, and fourth is the optimized index with 5% deletions. This gives me a single index w/ 4 different commit points, so I can then benchmark searching against any of those 4. Mike On Tue, Feb 15, 2011 at 4:43 AM, Jan Høydahl <jan....@cominvent.com> wrote: > Yes and no. The index grows like an onion adding new segments for each commit. > There is no API to remove the newly added segments, but I guess you could > hack something. > The other problem is that as soon as you trigger an optimize() all history is > gone as the segments are merged into one. Optimize normally happens > automatically behind the scenes. You could turn off merging but that will > badly hurt your performance after some time and ultimately crash your OS. > > Since you only need a few versions back, you COULD write your own custom > mergePolicy, always preserving at least N versions. But beware that a > "version" may be ONE document or 10000 documents, depending on how you commit > or if autoCommit is active. so if you go this route you also need strict > control over your commits. > > Perhaps best option is to handle this on feeding client side, where you keep > a buffer of N last docs. Then you can freely roll back or re-index as you > choose, based on time, number of docs etc. > > -- > Jan Høydahl, search solution architect > Cominvent AS - www.cominvent.com > > On 15. feb. 2011, at 01.21, Tri Nguyen wrote: > >> Hi, >> >> Does solr version each index build? >> >> We'd like to be able to rollback to not just a previous version but maybe a >> few >> version before the current one. >> >> Thanks, >> >> Tri > >
