[ 
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jukka Zitting updated JCR-3534:
-------------------------------

    Fix Version/s: 2.7.1
                   2.6.2

Tagging this for the 2.6 branch. I think the solution here is getting stable 
enough to be backported.

> I'm not sure about 3 as with URIs potentially pointing to localhost such a 
> mechanism may become unreliable

Good point. The connection URI might not even be easily available if a data 
source is used.

                
> Efficient copying of binaries across repositories with the same data store
> --------------------------------------------------------------------------
>
>                 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
>            Assignee: Tommaso Teofili
>             Fix For: 2.6.2, 2.7.1
>
>         Attachments: JCR-3534.2.patch, JCR-3534.3.patch, JCR-3534.4.patch, 
> JCR-3534.6.patch, JCR-3534.7.patch, JCR-3534.patch, 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

Reply via email to