[
https://issues.apache.org/jira/browse/JCR-3093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13125921#comment-13125921
]
angela commented on JCR-3093:
-----------------------------
played around with the possibilities listed above. retrieving the json-ser of
the parent node could
potentially be cumbersome if a given session is allowed to retrieve the
property but not the parent node.
finally came up with a different solution:
the jcr-property resources expose a protected dav property that corresponds to
the string representation
such as retrieved by Property.getString(). it is available for single-valued
non-binary properties only.
consequently, getPropertyInfo only results in an additional GET request for
non-binary multivalued properties.
for any other properties (single-value or binary) a single PROPFIND request is
sufficient to retrieve the
information used to build the PropertyInfo object.
running the jackrabbit-jcr2dav ConformanceTest with tracing the average amount
of time spent with the
getPropertyInfo calls (NOTE that the test do not contain huge binary
properties):
- original code: 3248
- patch 2 request: 7529
- final patch: 4640
futher improvement could be achieved by addressing JCR-2073 that would avoid
redundant calls
to getPropertyInfo.
> 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
> Assignee: angela
> Fix For: 2.3.2
>
> 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
