lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrzej Bialecki (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-3560) add extra safety to concrete codec implementations
Date Sat, 05 Nov 2011 15:12:51 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144714#comment-13144714
] 

Andrzej Bialecki  commented on LUCENE-3560:
-------------------------------------------

Let's not go too far either... we want people to write and contribute new codecs, if we make
the api too onerous to use then we risk a lot of copy&paste-ing (e.g. I'd like to extend
an existing codec to add one file to files() - bummer, I have to reimplement the whole codec
now). So let's leave extensibility where it's clear that stuff can be extended with no harm
(or "no harm if you read the instructions").
                
> add extra safety to concrete codec implementations
> --------------------------------------------------
>
>                 Key: LUCENE-3560
>                 URL: https://issues.apache.org/jira/browse/LUCENE-3560
>             Project: Lucene - Java
>          Issue Type: Improvement
>    Affects Versions: 4.0
>            Reporter: Robert Muir
>         Attachments: LUCENE-3560.patch
>
>
> In LUCENE-3490, we reorganized the codec model, and a key part of this is that Codecs
are "safer"
> and don't rely upon client-side configuration: IndexReader doesn't take Codec or anything
of that 
> nature, only IndexWriter.
> Instead for "read" all codecs are initialized from the classpath via a no-arg ctor from
Java's 
> Service Provider Mechanism.
> So, although Codecs can still take parameters in the constructors, be subclassable, etc
(for passing
> to IndexWriter), this enforces that they must write any configuration information they
need into
> the index, so that we don't have a flimsy API.
> I think we should go even further, for additional safety. Any methods on our concrete
codecs that
> are not intended to be subclassed should be final, and we should add assertions to verify
this.
> For example, SimpleText's files() implementation should be final. If you want to make
an extension
> of simpletext that has additional files, then this is a different index format and should
have a
> different name!
> Note: This doesn't stop extensibility, only stupid mistakes. 
> For example, this means that Lucene40Codec's postingsFormat() implementation is final,
even though 
> it offers a configurable "hook" (getPostingsFormatForField) for you to specify per-field
postings 
> formats (which it writes into a .per file into the index, so that it knows how to read
each field).
> {code}
> private final PostingsFormat postingsFormat = new PerFieldPostingsFormat() {
>   @Override
>   public PostingsFormat getPostingsFormatForField(String field) {
>     return Lucene40Codec.this.getPostingsFormatForField(field);
>   }
> };
> ...
> @Override
> public final PostingsFormat postingsFormat() {
>   return postingsFormat;
> }
> ...
>   /** Returns the postings format that should be used for writing 
>    *  new segments of <code>field</code>.
>    *  
>    *  The default implementation always returns "Lucene40"
>    */
>   public PostingsFormat getPostingsFormatForField(String field) {
>     return defaultFormat;
>   }
> {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message