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 09:22:15 GMT

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

View raw message