Hi Arek,

Regarding CompositeBlobStore -- what if customer changes the storage
rules in the meantime (refers also to Curation section). This will
result in the new layout for writes but binaries won't be read
correctly, am I right?
I guess this could be resolved by nesting: CompositeBlobStore with old
rules and CompositeBlobStore with new rules in OverlayBlobStore, but I
see that "curation" is for now deferred to other topic but still I
think this is quite important IMO to think about it a little upfront
at least for this blob store type.


Agreed.  I’m just not sure how to go about it yet, open to ideas here. :)

Perhaps a better approach would be to only have one type.  Use the overlay
approach in Composite blob store, meaning reads will be tried to all
delegates, but if rules are supplied we use those for priority before
checking any other stores.  In that case, when configuration change happens
the blob could still be found, but it would be suboptimal because it isn’t
in the expected location.  The blob store could at that point start an
async background job to move it to the correct location if needed.

WDYT?

-MR

Reply via email to