[
https://issues.apache.org/jira/browse/OAK-7083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16431429#comment-16431429
]
Matt Ryan commented on OAK-7083:
--------------------------------
Encoding after the delegate is called won't work as the blob has already been
uploaded by the delegate by that point.
After thinking about this further I decided not to pursue the concept of
encoding the data store identifier in the blob id for two additional reasons.
First, this approach prevents any possible future uses in which a blob could be
stored in more than one place. Using the {{CompositeDataStore}} to store blobs
in more than one data store and look them up based on some other criteria was
one of the originally identified possible use cases (for example, storing
multiple copies worldwide and retrieving from the closest data store, or
implementing service-redundant storage by storing in AWS and Azure
simultaneously).
Second, this approach will require a data migration for any existing user who
then wants to start using {{CompositeDataStore}} - all existing blobs would
have to be renamed.
So I've implemented a simpler solution based on a {{LoadingCache}} which is
currently in the pull request.
> CompositeDataStore - ReadOnly/ReadWrite Delegate Support
> --------------------------------------------------------
>
> Key: OAK-7083
> URL: https://issues.apache.org/jira/browse/OAK-7083
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: blob, blob-cloud, blob-cloud-azure, blob-plugins
> Reporter: Matt Ryan
> Assignee: Matt Ryan
> Priority: Major
>
> Support a specific composite data store use case, which is the following:
> * One instance uses no composite data store, but instead is using a single
> standard Oak data store (e.g. FileDataStore)
> * Another instance is created by snapshotting the first instance node store,
> and then uses a composite data store to refer to the first instance's data
> store read-only, and refers to a second data store as a writable data store
> One way this can be used is in creating a test or staging instance from a
> production instance. At creation, the test instance will look like
> production, but any changes made to the test instance do not affect
> production. The test instance can be quickly created from production by
> cloning only the node store, and not requiring a copy of all the data in the
> data store.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
