[
https://issues.apache.org/jira/browse/OAK-8186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16813403#comment-16813403
]
Francesco Mari commented on OAK-8186:
-------------------------------------
Surely the lower you implement the copy operation, the better the performance
will be. The point is not which kind of copy operation is going to be the
fastest, but how tight the coupling between your code and Oak's internals are
going to be.
If you build your system on top of the JCR API, you are going to be safe no
matter what implementation of the JCR API you use. If you use a custom API to
access the internals of Oak, you are bound to a specific configuration of Oak,
and of Oak only. Moreover, this this is going to create a backwards bind.
Assuming that we implement this feature in Oak, we will not be able to drop
support for this feature if we decide to change the internals of our
implementation. What if, at some point, we decide to save binaries on disk in
chunks instead of in one big file? We will not be able to do so without
breaking the contract for fast copies.
Oak lives below JCR, your system lives upon it. I'm not comfortable breaking
this boundary. I wasn't when the direct binary access was introduced, and I'm
definitely not comfortable now.
> Create API in OAK for file access to binaries in the repository.
> ----------------------------------------------------------------
>
> Key: OAK-8186
> URL: https://issues.apache.org/jira/browse/OAK-8186
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Reporter: Henry Saginor
> Priority: Major
> Attachments: FileCopyTest3.java, OAK File Access.jpg,
> fileCopyTest-0.0.1-SNAPSHOT.jar
>
>
> To get file access applications normally write binaries to temp files. It
> would be nice if an API existed to get file access directly from OAK. This
> might also meet some use cases documented at
> [https://wiki.apache.org/jackrabbit/JCR%20Binary%20Usecase]
> Suggested API and implementation can be found here [1]. Also, see attached
> diagram [2].
> I can create a patch if I can get some feedback. Note that suggested API
> makes it explicit that a temp file is created. I am not sure if direct access
> to files in datasore would be safe. But I am open to suggestions.
> [1]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/FileReferencable.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReference.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-api/src/main/java/org/apache/jackrabbit/oak/api/blob/TempFileReferenceProvider.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDSBlobTempFileReference.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-blob-plugins/src/main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/DataStoreBlobStore.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-segment-tar/src/main/java/org/apache/jackrabbit/oak/segment/SegmentBlob.java]
>
> [https://github.com/hsaginor/jackrabbit-oak/blob/directFileAccess/oak-store-spi/src/main/java/org/apache/jackrabbit/oak/plugins/value/jcr/BinaryImpl.java]
> [2]
> !OAK File Access.jpg!
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
