[
https://issues.apache.org/jira/browse/OAK-1667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961736#comment-13961736
]
Thomas Mueller commented on OAK-1667:
-------------------------------------
I think the important part is that this change needs to be compatible with the
old behavior, so that existing repositories will still work with this feature
enabled. As far as I see, once the patch is used, the feature can be enabled
and disabled, and things would still work.
I'm wondering what would happen if the patch is used and the feature is
enabled, then a few binaries are stored, and someone would switch back to the
old version of Oak (without the patch), or uses a shared FileDataStore and does
not upgrade the FileDataStore on all clients at the same time. It would be nice
if access those new binaries would fail, but also if garbage collection with
the old version would either fail or at least not delete those files. But I'm
not sure if this can be done (as we can't change the old code).
Other than that, the patch looks good to me.
> Encode Blob length as part of blobId in DataStoreBlobStore
> ----------------------------------------------------------
>
> Key: OAK-1667
> URL: https://issues.apache.org/jira/browse/OAK-1667
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Fix For: 1.1
>
> Attachments: OAK-1667.patch
>
>
> Currently to determine length of Blob in {{DataStoreBlobStore}} an explicit
> call is made to backing DataStore which in case of FileDataStore results in
> an OS call.
> As any file stored in DataStore is immutable and DataStore does not store the
> file in chunks the length information can be encoded in the BlobId itself and
> getLength call make use of that information
--
This message was sent by Atlassian JIRA
(v6.2#6252)
