[
https://issues.apache.org/jira/browse/JCR-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489995
]
Julian Reschke commented on JCR-851:
------------------------------------
Maybe I'm a bit slow, but I don't see how to do that.
In the write/read case, the QValue is instantiated without any knowledge where
the InputStream finally will be written to (or more precisely: who is going to
read it).
In the general case (I don't know the consumer), I will have to make a copy of
every byte read from it, and also have to take into account the case where the
consumer actually doesn't consume the whole stream. In this case, I can
preserve the contents of the stream either in memory or on disk.
The write to repository case theoretically can be optimized: the InputStream
held by the QValue would be replaced with the information required to get the
contents from the backing store later on. However, this assumes that the write
operation will succeed. It also doesn't take care of the case where the binary
property in the repository later on gets replaced by a new value, in which case
the information in the QValue object would become invalid.
Hint: if you feel the current interface is good enough, please propose a change
to SPI2JCR that implements QValue.getStream without making a copy of the
contents...
Best regards, Julian
> Handling of binary properties (streams) in QValue interface
> -----------------------------------------------------------
>
> Key: JCR-851
> URL: https://issues.apache.org/jira/browse/JCR-851
> Project: Jackrabbit
> Issue Type: Improvement
> Components: SPI
> Reporter: Julian Reschke
>
> The current SPI requires QValue to return new streams upon each call to
> getStream(). As far as I can tell, this essentially requires a QValue
> implementation to preserve the whole content of a stream, be it in memory or
> on disk.
> In particular (and unless I'm missing something), when importing large
> content into a repository, this causes the whole data stream to be written
> twice. We really should try to avoid that.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
