Hi, I’d be interested in ideas on how we should define configuration for delegate data stores for the CompositeDataStore.
One idea was proposed on-list earlier in [0]. I like this idea, but it is a unified node-store/data-store configuration concept that might take a bit longer to support than we want to handle right now, and may be a bit more invasive than we want to tackle at this stage in the release. For my POC I did a really simple configuration format, like this: datastore.1=dataStoreName:FileDataStore,className:org.apache.jackrabbit.oak.plugins.blob.datastore.OakCachingFDS,bundleName:org.apache.jackrabbit.oak-core,path:/Users/maryan/POCs/content_backflow_poc/ds_testing datastore.2=dataStoreName:FileDataStore,className:org.apache.jackrabbit.oak.plugins.blob.datastore.OakCachingFDS,bundleName:org.apache.jackrabbit.oak-core,path:/Users/maryan/POCs/content_backflow_poc/ds_production,readOnly:true I admit this is kinda ugly. Delegates are identified by starting with “datastore” - the rest of this part of the line is not super relevant other than to make each key different. Everything on the right of the “=“ is the value which gets passed to the service. The service or the data store itself has to parse the rest of the string. The rest of the string is key/value pairs, each pair separated by “,", each key separated from the value by “:”. Mostly I’m just indicating the delegate type, class path (so it can be created by reflection), and bundle name (so when the bundle changes state we know to take some action). Note that this relates to the earlier thread [1] regarding how delegates get created. The remainder gets passed to the delegate as configuration options. This approach isn’t super flexible and is hard to edit and read. Open to other ideas. Thoughts? [0] - http://oak.markmail.org/thread/zhnntcdxe5jj2rg2 [1] - http://oak.markmail.org/thread/4ouvpitv5zrypiqg -MR
