over in #3719 I take advantage of the ability of some "niche" storage backends (memory and local files) to write subchunks inside a shard. This is a huge performance win under the right conditions. It requires a set_range(key, value, byte_range) method, which most stores will not support.
Our monolithic Store abc makes this situation -- methods some stores have, but others do not -- hard to express. We either use boolean attributes like supports_x, hasattr, or other hacks. Alternatively, we define a protocol like SupportsSetRange, and have store classes that support set_range inherit from SupportsSetRange. IMO this is the best approach.
So... why don't we replace the entire Store abc with protocols? This seems like a much better way to express the compositional nature of storage backends than a monolithic abstract base class.
cc @kylebarron
over in #3719 I take advantage of the ability of some "niche" storage backends (memory and local files) to write subchunks inside a shard. This is a huge performance win under the right conditions. It requires a
set_range(key, value, byte_range)method, which most stores will not support.Our monolithic
Storeabc makes this situation -- methods some stores have, but others do not -- hard to express. We either use boolean attributes likesupports_x, hasattr, or other hacks. Alternatively, we define a protocol likeSupportsSetRange, and have store classes that supportset_rangeinherit fromSupportsSetRange. IMO this is the best approach.So... why don't we replace the entire
Storeabc with protocols? This seems like a much better way to express the compositional nature of storage backends than a monolithic abstract base class.cc @kylebarron