.
Deletions are not idempotent: if you add a doc w/ term X, delete by
term X, add a new doc with term X... that's very different than if you
moved the delete op to the end. Ie the deletion only applies to the
docs added before it.
Mike
On Mon, Apr 5, 2010 at 12:45 AM, Babak Farhang farh
. 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
[Late to this party, but thought I'd chime in]
I think this layer concept is right on. But I'm wondering about the
life cycle of these layers. Do layers live forever? Or do they
collapse at some point? (Like, as I think was already pointed out,
deletes are when segments are merged today.)
that it may maintain the
docId chain.
What do you think?
On Fri, Apr 2, 2010 at 4:56 AM, Grant Ingersoll gsing...@apache.org wrote:
On Apr 2, 2010, at 2:50 AM, Babak Farhang wrote:
[Late to this party, but thought I'd chime in]
I think this layer concept is right on. But I'm wondering about
Grant,
Reading your post a 3rd time, I see my suggestion is in fact the
approach you describe. Sorry for being redundant.
-Babak
On Fri, Apr 2, 2010 at 11:25 PM, Babak Farhang farh...@gmail.com wrote:
I think they get merged in by the merger, ideally in the background.
That sounds sensible
maturity, and their back compat commitments. The demo and getting
started guies could also be expanded to refrence the contrib jars that
contain code many people may want to reuse...
Here's an idea. Each contrib is really a project onto its own. And any
project, I suggest, ought to have its
you run any threaded performance tests comparing the two?
Mike
Babak Farhang farh...@gmail.com wrote:
Hi everyone,
I've been working on a library called Skwish to complement indexes
like Lucene, for blob storage and retrieval. This is nothing more
than a structured implementation
...@holsman.net
To: java-dev@lucene.apache.org
Sent: Friday, December 26, 2008 5:40:36 AM
Subject: Re: Blob storage
Babak Farhang wrote:
Most of all, I'm trying to communicate an *idea* which itself cannot
be encumbered by any license, anyway. But if you want to incorporate
some of this code
PS I am relicensing skwish under Apache 2.0 and am in the process of
re-releasing it from the project website under this new license. (I'm
not that efficient with such chores, so bear with me :)
DONE
On Sat, Dec 27, 2008 at 1:15 AM, Babak Farhang farh...@gmail.com wrote
:)
On Fri, Dec 26, 2008 at 3:40 AM, Ian Holsman li...@holsman.net wrote:
Babak Farhang wrote:
Most of all, I'm trying to communicate an *idea* which itself cannot
be encumbered by any license, anyway. But if you want to incorporate
some of this code into an asf project, I'd be happy to also
of this conversation..
On Fri, Dec 26, 2008 at 12:46 AM, Noble Paul നോബിള് नोब्ळ्
noble.p...@gmail.com wrote:
The license is GPL . It cannont be used directly in any apache projects
On Fri, Dec 26, 2008 at 12:47 PM, Babak Farhang farh...@gmail.com wrote:
I assume one could use Skwish instead
normal stored fields to
store retrieve document data?
Have you run any threaded performance tests comparing the two?
Mike
Babak Farhang farh...@gmail.com wrote:
Hi everyone,
I've been working on a library called Skwish to complement indexes
like Lucene, for blob storage and retrieval
Hi everyone,
I've been working on a library called Skwish to complement indexes
like Lucene, for blob storage and retrieval. This is nothing more
than a structured implementation of storing all the files in one file
and managing their offsets in another. The idea is to provide a fast,
13 matches
Mail list logo
