[
https://issues.apache.org/jira/browse/JCR-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489978
]
Julian Reschke commented on JCR-851:
------------------------------------
I really meant "SPI": the SPI contract needs to be sufficiently clear, and
JCR2SPI has to work against that.
That being said, the problem seems to be that JCR2SPI likes to keep the QValue,
thus SPI requires QValue to allow multiple calls to getStream() (requiring new
stream instances to be returned). Supporting multiple calls to getStream() is
simple for multiple reads, but not for the case where a property is set and
then re-read (such as in some of the TCK tests).
One solution to that would be to:
- require getStream() to *either* return a new stream instance, or to throw an
IllegalStateException, and
- modify JCR2SPI to obtain a new QValue if getStream() on the cached value
yielded that exception.
That would allow JCR2SPI to keep QValue instances in most cases (read/read),
but would make it much simpler to implement the write/read sequence.
> 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.
