lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Engels" <>
Subject RE: release & migration plan
Date Mon, 12 Jul 2004 17:15:03 GMT
I think the IndexReader and IndexWriter should be interfaces, and change the
codebase to use the interface where possible.

Robert Engels

-----Original Message-----
From: Doug Cutting []
Sent: Monday, July 12, 2004 12:10 PM
To: Lucene Developers List
Subject: release & migration plan

I think perhaps it is time to make some incompatible changes to Lucene's
API.  There are a number of places where it is showing its age.  I'd
like to try to make as many API changes at once as is possible, so that
folks only have to port application code once.

I propose we do this as follows:

1. Make a 1.9 release which has all the new APIs and deprecates all the
outdated APIs.  Existing applications should compile and run fine, but
with lots of deprecation warnings.

2. Make a 2.0 release which removes all deprecated code.

Thus 1.9 would be a migration release.  Before an application is moved
to 2.0, folks should first make sure that it compiles against 1.9
without deprecation warnings.  Once it does then it should move to 2.0
without incident.

Does this sound like a good plan?

What changes would I like to see in the API?  Here are a few candidates:

1. Replace Field factory methods (Field.Text, Field.Keyword, etc.) with
a few methods that use type-safe enumerations, as described in:

2. Similarly, replace BooleanQuery.add() with a type-safe enumeration,
also as described in:

3. Replace public IndexWriter fields (mergeFactor, minMergeDocs, etc.)
with get/set accessors.  Also, minMergeDocs should be renamed

4. Rename PhrasePrefixQuery to be something like MultiPhraseQuery.  Also
make MultipleTermPositions a private nested class of this, as this is
the only place MultipleTermPositions is used.

5. Rename InputSteam to IndexInput and OutputStream to IndexOutput.
Also make both of these interfaces and add BufferedIndexInput and
BufferedIndexOutput as the implementation used by FSDirectory,
RAMDirectory, etc.  This would permit unbuffered and native
implementations (e.g., that use mmap) that could potentially speed
things considerably.

6. Replace DateField with something that formats dates suitably for

7. Move language-specific analyzers into separate downloads?

8. Add support for span queries to query parser?

Do you have other candidates?


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

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

View raw message