Yes it is !
This is what I am getting at when I said the design is moving all
over the place.
The thread is "explicit commits", so I apologize for getting lost.
It just seems that we should design a new high-level class class
Repository and design that API. It might use Lucene IndexReader and
IndexWriter internally, but those should be made into package level
interfaces.
That way all of the implementation of all these "needs" can be
properly hidden, and we can have a coherent API that really
represents the available functionality.
It may be that certain users don't need point in time searching,
durable commits, or some of the other features. By hiding this behind
another layer I think it will be far easier to implement and maintain.
On Jan 16, 2007, at 3:29 PM, Yonik Seeley wrote:
On 1/16/07, robert engels <[EMAIL PROTECTED]> wrote:
You have the same problem if there is an existing reader open, so
what is the difference? You can't remove the segments there either.
The disk space for the segments is currently removed if no one has
them open... this is quite a bit different than guaranteeing that a
reader in the future will be able to open an index in the past.
-Yonik
On Jan 16, 2007, at 3:18 PM, Yonik Seeley wrote:
> On 1/16/07, Doug Cutting <[EMAIL PROTECTED]> wrote:
>> Remind me, why do we have to update the segments file except at
>> close?
>> I'm sure there's a good reason, and that's central to this
>> discussion.
>
> If segments are removed because of a merge, a new reader coming
along
> will have problems opening the index if the segments file isn't
> updated to reflect that.
>
> One could keep around all old segments until a close() but that
would
> cost disk space.
>
> -Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
