Azure Cosmos multiple stores per container

[rylev]

Fixes #2951

This adds support in the Azure Cosmos key-value implementation for storing multiple key-value stores in a single Azure Cosmos container.

IMPORTANT: This currently does not change the Spin CLI experience at all. Users of Spin CLI continue to have the 1 to 1 relationship between containers and key-value stores. This only allows Spin runtime embedders the ability to have many stores per containers. We can consider changing the default behavior for the Spin CLI in the future, but this might need to be at a major version change.

For embedders who provide an app_id to the KeyValueAzureCosmos, stores will be created in the supplied container and each key/value pair will include a partition_key field in the form of "$app_id/$store_id".

cc @devigned

[calebschoepp]

I have very little familiarity with this code, but reading through it it seems plausibly correct!

[kate-goldenring]

LGTM. Love that the enables users to get more out of one cosmos container. It would be nice to add some unit tests, maybe with something like mockall to assert queries and partitions are correctly set.

[kate-goldenring]

Suggested change

	/// When `app_id` is provided, the store will a partition key of `$app_id/$store_name`,
	/// When `app_id` is provided, the store will be a partition key of `$app_id/$store_name`,

[kate-goldenring]

What is the purpose of this trailing \?

[rylev]

We're pushing single quote (') on to the end of the query (to close the single quote that comes right after the =). The \ escapes the ' character since characters are always themselves enclosed in ''.

[kate-goldenring]

I am testing this locally and gets don't seem to be working as expected despite the query being formulated as expected:

SELECT * FROM c WHERE c.id='wow' AND c.partition_key='foo/default'

(I hard coded app id into spin to test this out for a default store)

[kate-goldenring]

Is there a reason we don't set partition here instead of suffixing the request? Are we anticipating gets across stores?

    async fn get_pair(&self, key: &str) -> Result<Option<Pair>, Error> {
        let query = self
            .client
            .query_documents(Query::new(self.get_query(key)))
            .query_cross_partition(true)
            .max_item_count(1);

[rylev]

I'm not sure I understand your question. Can you reformulate it?

[kate-goldenring]

I realized what my issue was. The implementation assumes that the container "Partition Key" is set to /partition_key. You mention this in the description but i skipped over it accidentally. Maybe naming the partition key something else such as "store_identifier" would help.

[rylev]

I've switched from the partition_key partition key to store_id. Hopefully things are a bit clearer. I'm going to merge now to unblock some other work, and I'll add tests in a new PR.