lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick Hunt (JIRA)" <>
Subject [jira] [Updated] (SOLR-4224) refactor JavaBinCodec input stream definition to enhance reuse
Date Thu, 20 Dec 2012 18:01:16 GMT


Patrick Hunt updated SOLR-4224:

    Attachment: SOLR-4224.patch

The attached patch implements a refactoring that allows an arbitrary InputStream/DataInput
implementation to be used. I've taken an approach that minimizes impact of the changes. It's
pretty mechanical - replace FastInputStream in the JavaBinCodec API definition with an abstract
> refactor JavaBinCodec input stream definition to enhance reuse
> --------------------------------------------------------------
>                 Key: SOLR-4224
>                 URL:
>             Project: Solr
>          Issue Type: Improvement
>          Components: clients - java
>    Affects Versions: 4.0
>            Reporter: Patrick Hunt
>            Assignee: Patrick Hunt
>         Attachments: SOLR-4224.patch
> JavaBinCodec currently requires use of the concrete "FastInputStream" when unmarshalling
a record. A JavaBinCodec API that takes an interface or abstract implementation would allow
greater reuse.
> In my particular case I am trying to use JavaBinCodec to marshal/unmarshal from an data
source that doesn't allow buffering. The semantics are such that I can read only a single
record from the input source. The buffering in FastInputStream is reading information contained
in the second record. No state other than the input data source itself is available to "cache"
the FastInputStream between calls. As a result I'm losing the second record. I would like
to provide an InputStream/DataInput that doesn't do any buffering.

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

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

View raw message