[
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
