[
https://issues.apache.org/jira/browse/JCR-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489939
]
angela commented on JCR-851:
----------------------------
jukka, maybe i didn't get your post. from what i understood, i think you are
mistaken about the current
usage of QValue in the SPI:
they are used both for reading from the SPI impl and upon creation/modification
of existing properties.
therefore:
> The most usual (only?) reason for a client to create QValues is when the
> client wants to
> store content in the repository
is probably not totally correct, isn't it? i was told recently that almost
everything was reading :)
since in contrast to the jackrabbit core QValue objects are always created by a
factory and both QValueFactory and QValue itself are interfaces defined by the
SPI api, i would argue that it's an implementation detail (which might or
might not be crucial) if a large binary is stored on the server upon creation
or not.
> 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.
