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 Tue, 11 Oct 2011 12:45:11 GMT

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

angela commented on JCR-3093:
-----------------------------

thanks for the patch. there is one thing that is wrong IMO:
 
- the path parameter for the PropertyInfoImpl constructor should be the path of the item and
not
  only the path part of the propertyID. i will fix that.

and then there is one thing i wasn't aware of: the information if a property is a binary isn't
known
upfront. consequently with the proposed solution an additional GET request is generated for
non-binary properties. whether or not that has an impact depends a bit on the frequency of
properties being directly accessed... just one thing i noticed.

an alternative solution was to get the json-serialization of the parent node and rearrange
the
results such that the requested propertyInfo is the first one in the iterator. according to
the
api contract the callers are required to properly deal with additional, "arbitrary" infos
being
returned from getItemInfos. that was suitable if there is a greater chance that the parent

node will be read as well (sooner or later)... if that's not the case retrieving the parent
and
the sibling properties add overhead for item processing on the client side.

yet another possibility was to guess whether a given propertyId refers to a binary property
(e.g. by adding that short cut for known binary property names (e.g. jcr:data))... don't really
like this one, but mentioning here for completeness.


                
> 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
>         Attachments: JCR-3093.patch
>
>
> 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
implementation
> 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

        

Mime
View raw message