[ https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604980#comment-13604980 ]
Jukka Zitting commented on JCR-3534: ------------------------------------ I'm not too excited about the idea of using a special READ_VALUE_BY_CONTENT_IDENTITY permission for this. It seems like a hack to get around the inherent security implications of a feature like this. Instead of exposing this at the JCR API level, to me it would feel more natural to handle this on a lower level. For example, the following pattern would require no API extensions or extra permissions, but would still allow the lower-level implementation to detect that we're talking to two repositories with the same data store and thus optimize the copying of the data: Repository repositoryA = ...; Session sessionA = repositoryA.login(...); Repository repositoryB = ...; Session sessionB = repositoryB.login(...); Binary binary = sessionA.getProperty(...).getBinary(); sessionB.getNode(...).setProperty(..., binary); > Add JackrabbitSession.getValueByContentId method > ------------------------------------------------ > > Key: JCR-3534 > URL: https://issues.apache.org/jira/browse/JCR-3534 > Project: Jackrabbit Content Repository > Issue Type: New Feature > Components: jackrabbit-api, jackrabbit-core > Affects Versions: 2.6 > Reporter: Felix Meschberger > Attachments: JCR-3534.patch > > > we have a couple of use cases, where we would like to leverage the global > data store to prevent sending around and copying around large binary data > unnecessarily: We have two separate Jackrabbit instances configured to use > the same DataStore (for the sake of this discussion assume we have the > problems of concurrent access and garbage collection under control). When > sending content from one instance to the other instance we don't want to send > potentially large binary data (e.g. video files) if not needed. > The idea is for the sender to just send the content identity from > JackrabbitValue.getContentIdentity(). The receiver would then check whether > the such content already exists and would reuse if so: > String ci = contentIdentity_from_sender; > try { > Value v = session.getValueByContentIdentity(ci); > Property p = targetNode.setProperty(propName, v); > } catch (ItemNotFoundException ie) { > // unknown or invalid content Identity > } catch (RepositoryException re) { > // some other exception > } > Thus the proposed JackrabbitSession.getValueByContentIdentity(String) method > would allow for round tripping the JackrabbitValue.getContentIdentity() > preventing superfluous binary data copying and moving. > See also the dev@ thread > http://jackrabbit.markmail.org/thread/gedk5jsrp6offkhi -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira