Hey guys,
Following the Lucene dev mailing list for sometime now, I am concerned that
lucene is slowing losing all the simplicity and become a complicated mess.
I think keeping IndexReader and IndexWriter the way it works in 1.2 even is
better, no?
Software should be designed to be simple to us
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-565:
-
Assignee: Michael McCandless
> Supporting deleteDocuments in IndexWriter (Code an
[
https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reopened LUCENE-565:
---
Reopening based on recent discussions on java-dev:
http://www.gossamer-threads.com/l
On 2/9/07, Doug Cutting <[EMAIL PROTECTED]> wrote:
Yonik Seeley wrote:
> As long as you wouldn't object to a org.apache.lucene package in Solr...
> With the understanding of course, that the onus would be on Solr developers
> to keep up with any changes.
I wouldn't object to that. Would you?
Yonik Seeley wrote:
As long as you wouldn't object to a org.apache.lucene package in Solr...
With the understanding of course, that the onus would be on Solr developers
to keep up with any changes.
I wouldn't object to that. Would you? Solr's developers are pretty
on-top of Lucene and should
: > (see above), and it doesn't impact non-deleting uses (which Hoss assures
: > us it won't).
: I agree w/ Hoss: the way NewIndexModifier works, if you don't do any
: deletes then there's no added cost (well, only some if statements) to
: the "addDocument only" case because no readers are opened
On 2/9/07, Doug Cutting <[EMAIL PROTECTED]> wrote:
Michael McCandless wrote:
> I agree extensions points are nice. Maybe we could leave the
> extension points ("doAfterFlushRamSegments", etc.) but merge
> NewIndexModifier into IndexWriter?
>
> Though I do worry that by adding these extension poi
9 feb 2007 kl. 18.28 skrev Doug Cutting:
A single IndexWriter would be ideal
How about sneaking in a couple of interfaces at this point? I'll
settle with IndexReaderInterface and IndexWriterInterface. How about
having them extend IndexDocumentDeleter and IndexDocumentInserter?
Ceterum c
Doug Cutting wrote:
Michael McCandless wrote:
I agree extensions points are nice. Maybe we could leave the
extension points ("doAfterFlushRamSegments", etc.) but merge
NewIndexModifier into IndexWriter?
Though I do worry that by adding these extension points we tie our
hands for later.
I thi
Michael McCandless wrote:
I agree extensions points are nice. Maybe we could leave the
extension points ("doAfterFlushRamSegments", etc.) but merge
NewIndexModifier into IndexWriter?
Though I do worry that by adding these extension points we tie our
hands for later.
I think this is a valid co
OK, I'm now +1 on release
On Feb 1, 2007, at 6:57 AM, Grant Ingersoll wrote:
-1
I would like a few more days to get https://issues.apache.org/jira/
browse/LUCENE-762, as it may involve moving some classes and I
don't want to do that after an official release. It is not a major
issue, bu
[
https://issues.apache.org/jira/browse/LUCENE-626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12471679
]
Karl Wettin commented on LUCENE-626:
Almost all TODO:s in the code (mostly refactoring to support alternative sin
12 matches
Mail list logo
