jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "angela (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (JCR-3093) Inconsistency between Session.getProperty and Node.getProperty for binary values
Date Wed, 05 Oct 2011 13:14:34 GMT

    [ https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13120928#comment-13120928

angela commented on JCR-3093:

public void testBinaryLength() throws Exception {
        Node test = testRootNode.addNode("test");
        Property p = test.setProperty("prop", generateValue());

        Session s = getHelper().getSuperuserSession();
        try {
            Node n = s.getNode(Text.getRelativeParent(p.getPath(), 1));
            Property prop = n.getProperty("prop");

           // alternative call to demonstrate the difference:
           // Property prop = s.getProperty(p.getPath());

            long l = prop.getLength();
        } finally {
> Inconsistency between Session.getProperty and Node.getProperty for binary values
> --------------------------------------------------------------------------------
>                 Key: JCR-3093
>                 URL: https://issues.apache.org/jira/browse/JCR-3093
>             Project: Jackrabbit Content Repository
>          Issue Type: Bug
>          Components: jackrabbit-spi2dav
>            Reporter: angela
> there an inconsistency in the binary handling between the batch-reading facility and
those cases where a property is directly
> accessed without having accessed the parent node before.
> this issue came up with timothee maret running into performance issues when retrieving
the length of a binary property:
> if the property-entry has been created in the run of a batch-read operation the corresponding
property-data object
> contains internal values that contain the length of the binary (such as transported with
the json response) and only
> read the data from the server if the value stream is explicitly requested.
> however, if the property is accessed directly (e.g. Session.getProperty or Node.getProperty
with a relative path) 
> a GET request is made to the corresponding dav resource and the stream is read immediately.
> possible solution:
> if RepositoryService#getItemInfos(SessionInfo, ItemId) is called with a PropertyId the
> should not result in a GET request to the corresponding resource by calling super.getPropertyInfo(sessionInfo,
(PropertyId) itemId).
> instead it should be consistent with the batch-read and only make a PROPFIND request
for the property
> length. the returned PropertyInfo object would in that case be identical to the one generated
by the batch-read functionality.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message