microsoft
DCR: change BotState to use template based storage keys
Issue
The addition of remote skills is requiring that we rev the structure of our state storage keys which could break existing bots if we're not careful. Ideally we can come up with a solution that doesn't break existing bots and makes us more robust to additional key changes in the future.
Proposed change
One idea I have is to be more transparent with regards to the storage keys being used by moving away from our existing UserState and ConversationState classes and instead make the root BotState class template based. So to create your bots various state instances you could do the following:
const userState = new BotState(storage, '{callerId}/{botId}/{channelId}/users/{userId}');
const conversationState = new BotState(storage, '{callerId}/{botId}/{channelId}/conversations/{conversationId}');
We would leave the legacy UserState and ConversationState classes using the old keys but all of our samples would be updated to use the new keys above.
Moving forward if we need to make further changes to our storage keys we can simple update the samples without risk of breaking any existing bots.
Component Impact
BotState class and samples.
Customer Impact
Should be a non-breaking change for customers.
Tracking Status
Dotnet SDK
- [ ] PR
- [ ] Merged
Javascript SDK
- [ ] PR
- [ ] Merged
Java SDK
- [ ] PR
- [ ] Merged
Python SDK
- [ ] PR
- [ ] Merged
Emulator
- [ ] PR
- [ ] Merged
Samples
- [ ] PR
- [ ] Merged
Docs
- [ ] PR
- [ ] Merged
Tools
- [ ] PR
- [ ] Merged
[dcr]
I like this personally because it also offers the ability for very simple bots to key off a simple user id for channel id which would make it easier to query in the db.
In many ways this is an attractive model, certainly explicitly echos the docs and the code we have in sample 42. Its less magic and implicitly puts the application in teh drivign seat.
We have made the idea of the differing state models (user and conversation) clear in the docs and in samples. The docs and samples show the developer how to construct the appropriate key.
However, in the 4.0 product we already have a solution here, it is to subclass BotState and inline the template you want to use there in the overload method GetStorageKey. Given that we would provide a constant or at least a function that encapsulated this template the new mechanism is not that different, only differing in the way you mechanically extend it, OK better but not much better as its still the same BotState/Accessor/Storage world. Agreed the subclassing was probably not the most elegant extensibility mechanism but that is what the designers chose.
Specifically if the user (for "skills"?) wanted to include the caller-id field in the key they can easily do this by providing a new subclass of BotState and override the GetStorageKey using a regular string print statement along the lines of the one shown above.
