lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Muir (Updated) (JIRA)" <>
Subject [jira] [Updated] (LUCENE-3613) remove .codecs.DefaultXXXX and split into 3x/4x impls
Date Fri, 02 Dec 2011 17:43:39 GMT


Robert Muir updated LUCENE-3613:

    Attachment: LUCENE-3613.patch

Here's a first patch, moving this Default* stuff to Lucene40 codec. 

Some preflex stuff is obviously using Lucene40 impls still, but this just reflects reality.
> remove .codecs.DefaultXXXX and split into 3x/4x impls
> -----------------------------------------------------
>                 Key: LUCENE-3613
>                 URL:
>             Project: Lucene - Java
>          Issue Type: Task
>    Affects Versions: 4.0
>            Reporter: Robert Muir
>         Attachments: LUCENE-3613.patch
> Currently there is a lot of shared codec implementations for things like
> field infos, segment infos, stored fields, term vectors under the .codecs 
> package with the name Default*
> I think actually the .codecs package should be our abstract codec apis,
> and the implementations should be under the respective codecs.
> Also, lots of these implementations are still 'shared' across the 3.x and 4.x
> formats, but shouldn't be: the 4.x versions should be "clean", and the 3.x 
> versions should have all the backwards cruft.
> Additionally, the "PreFlexRW" should be writing this stuff in 3.x format,
> but today it does not (it writes a 3.x index repackaged in a 4.x "container").
> Really PreFlexRW needs to write indexes that are exactly like the 3.x format
> (if you opened them up in lucene 3.x you could read them!). When this works
> then we know that codecs will actually work for our backwards compatibility needs
> and we know that we have good index backwards compatibility testing. 
> For starters we could just pick some 3.x version of lucene and wire PreFlexRW
> to it... in the future maybe the writer should take a version param so it
> can actually simulate different minor versions.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:!default.jspa
For more information on JIRA, see:


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

View raw message