jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Julian Reschke (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-851) Handling of binary properties (streams) in QValue interface
Date Thu, 19 Apr 2007 10:29:15 GMT

    [ 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.

View raw message