Sure. Because of the write once principle. But at some cost (duplicated data). I was just agreeing that it would not be a good idea to bake in version-ing by keeping the layers around forever in a merged index; I wasn't keying in on transactions per se.
Speaking of transactions: I'm not sure if we should worry about this much yet, but with "updates" the order of the transaction commits seems important. I think commit order is less important today in Lucene because its model supports only 2 types of events: document creation--which only happens once, and document deletion, which is idempotent. What do you think? Will commits have to be ordered if we introduce updates? Or does the onus of maintaining order fall on the application? -Babak On Sat, Apr 3, 2010 at 3:28 AM, Michael McCandless <luc...@mikemccandless.com> wrote: > On Sat, Apr 3, 2010 at 1:25 AM, Babak Farhang <farh...@gmail.com> wrote: >>> I think they get merged in by the merger, ideally in the background. >> >> That sounds sensible. (In other words, we wont concern ourselves with >> roll backs--something possible while a "layer" is still around.) > > Actually roll backs would still be very possible even if layers are merged. > > Ie, one could keep multiple commits around, and the older commits > would still be referring to the old postings + layers, keeping them > alive. > > Lucene would still be transactional with such an approach. > > Mike > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org