Amit Jain commented on OAK-7083:

bq. IIRC the approach was to tie into blob ID scanning at startup (OAK-7089) 
and to build Bloom filters mapping the blob IDs to the delegate (OAK-7090). 
I think rebuilding the filters would be problematic as they would be time 
consuming at the startup. 

bq. the use case for this describes the secondary system as a "staging" or 
"test" system, I suggest it is acceptable for now to take the slight 
performance hit on the secondary system in favor of getting the code reviewed
Well it does not stop from making progress. But I think I would consider it 
complete only when we sorted this out. Also, as you had mentioned earlier, 
rather than looking at the system as a test/production I think we need to 
enable the setup for a Read only/Writable use case and the performance will be 
an important aspect for that.

> 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

Reply via email to