lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Babak Farhang <>
Subject Re: Incremental Field Updates
Date Mon, 05 Apr 2010 04:45:02 GMT
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


On Sat, Apr 3, 2010 at 3:28 AM, Michael McCandless
<> wrote:
> On Sat, Apr 3, 2010 at 1:25 AM, Babak Farhang <> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message