jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting (JIRA)" <j...@apache.org>
Subject [jira] Commented: (JCR-851) Handling of binary properties (streams) in QValue interface
Date Wed, 18 Apr 2007 20:42:15 GMT

    [ https://issues.apache.org/jira/browse/JCR-851?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12489878
] 

Jukka Zitting commented on JCR-851:
-----------------------------------

I'm not sure I follow you. What kind of an alternative contract do you have in mind?

AFAIUI it never makes sense to have (large) binaries associated directly with the QValue instances.
They should always be stored on the server-side and the QValue instance should only hold a
reference or identifier to the backend storage. Calling getStream() will request the binary
to be streamed from the backend. This solution should cover both reading and writing of values
pretty well.

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


Mime
View raw message