[
https://issues.apache.org/jira/browse/JCR-3534?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651740#comment-13651740
]
angela edited comment on JCR-3534 at 5/8/13 9:26 AM:
-----------------------------------------------------
+1 for marcels comment.
one more comment from my side:
the modification to the repository.xml looks a bit suspicious to me:
- <DataStore class="org.apache.jackrabbit.core.data.FileDataStore"/>
+ <DataStore class="org.apache.jackrabbit.core.data.FileDataStore">
+ <param name="secret" value="a very well kept secret"/>
+ </DataStore>
there was something similar present for the trusted-credentials configuration
(aka pseudo-sso), which we finally deprecated (no longer supported in oak).
that's why i am not too happy about this entry...
maybe we can find a better solution?
or at least discuss on how to properly solved that in oak.... then i would just
consider this a temporary work around in the instable 2.7 cycle.
was (Author: anchela):
+1 for marcels comment.
one more comment from my side:
the modification to the repository.xml looks a bit suspicious to me:
- <DataStore class="org.apache.jackrabbit.core.data.FileDataStore"/>
+ <DataStore class="org.apache.jackrabbit.core.data.FileDataStore">
+ <param name="secret" value="a very well kept secret"/>
+ </DataStore>
there was something similar create for the trusted-credentials configuration
(aka pseudo-sso), which we finally deprecated (no longer supported in oak).
that's why i am not too happy about this entry...
maybe we can find a better solution?
or at least discuss on how to properly solved that in oak.... then i would just
consider this a temporary work around in the instable 2.7 cycle.
> 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
> Attachments: JCR-3534.2.patch, JCR-3534.3.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
