Partial context updates

[pseusys]

Description

Context storages are updated partially now instead of reading and writing whole data at once.

Checklist

• I have covered the code with tests
• I have added comments to my code to help others understand it
• I have updated the documentation to reflect the changes
• I have performed a self-review of the changes
• Consider extending UpdateScheme from BaseModel
• Decide how we want to use clear method.

[RLKRo]

It'd be better to define a method for saving context in DBContextStorage (i.e. ContextStorage method that accepts Context and saves it).

That way we can send all changes in one commit because there'd be access to engine from ContextStorage.

Right now we basically do

COMMIT main_info
COMMIT labels_added_modified
COMMIT labels_removed
COMMIT requests_added_modified
COMMIT requests_removed

Instead of a single

COMMIT main_info, labels_added_modified, labels_removed, requests_added_modified, requests_removed

Why this might be relevant: in case one of the methods fails we don't want others to succeed (this will lead to a broken context). And we can also have one place where we can process the errors.

I think we should improve db context storage api as a patch after release.

[pseusys]

Yes, we could. However, I am not sure that even for SQL databases executing many operations with one "connection" would protect us from breaking context structure (i.e. I don't think that writes will become atomic), however we can try.

[RLKRo]

Why not yield from self.keys()?
I.e.:

1. Why not use self.keys() regardless of the _storage?
2. Why not use yield from?

[pseusys]

I just forgot yield from construction exists at all, it is not widely used...

[RLKRo]

Make turns a property that returns an instance of a Turns class (needs to be defined) with async __getitem__.
So that the usage of turns is await ctx.turns[1:3] instead of await ctx.turns(slice(1, 3)).

Also, make it so that turns[1] is a single tuple while turns[1:2] is an iterable of tuples.

[RLKRo]

What I don't like about the way slices are processed now is that single key refers to a specific turn while a slice refers to a range of available turns.
So if there are only turns 1, 3, 5 available in ctx_dict, ctx_dict[1:2] == ctx_dict[3], ctx_dict[5], which is very confusing.

I think that there's little use case to getting ctx_dict items by their position in the keys.
So my proposal is:
Allow only

1. ctx_dict[non-neg-int] -- return element on turn non-neg-int (turn number is a non-negative integer);
2. ctx_dict[non-neg-int1:non-neg-int2:non-neg-int3] -- return elements starting from turn non-neg-int1 up to non-neg-int2 with a step of non-neg-int3.

(just in case: this proposal is for all the methods)

[pseusys]

I agree

[RLKRo]

This will always fail if key is Iterable.
This should be rewritten as

await self.load_items(keys if isinstance(keys, Iterable) else [keys])
if isinstance(key, Iterable):
    return [self._items.get(k, default) for k in key]
else:
    return self._items.get(k, default)

Tests for using get with iterable key should be added.

[pseusys]

Fair enough