[
https://issues.apache.org/jira/browse/SOLR-4224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
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
specification.
> refactor JavaBinCodec input stream definition to enhance reuse
> --------------------------------------------------------------
>
> Key: SOLR-4224
> URL: https://issues.apache.org/jira/browse/SOLR-4224
> 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: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
