-
Notifications
You must be signed in to change notification settings - Fork 57
Open
Labels
t-toolingIssues with this label are in the ownership of the tooling team.Issues with this label are in the ownership of the tooling team.
Milestone
Description
Current KVS storage client implementation follows several design choices that are not compatible together:
- Key name can have a dot in it - for example:
someKey.json - Locally, the values are stored in a files with that have
{keyName}{optionalSuffix} - Files without suffix are accepted by the storage client
This leads to several edge cases where the local client will behave differently than the platform client and to situations, where the local client will have to guess as the same situation can be interpreted in different ways.
Example edge cases:
- On the file system, there is a pre-existing file
someKey.bin
Possible interpretations:
- It is a key:
someKeyand its value is of type bytes - It is a key:
someKey.binand its value is of type bytes
The local client has to guess and pick one of those options
- Saving keys with names that look like filename with suffix can lead in missing keys.
This will create 2 keys on platform,
const kvs = await Actor.openKeyValueStore('keyTest', {forceCloud: true});
await kvs.setValue('INPUT', { key: 'value'});
await kvs.setValue('INPUT.json', { key: 'value2'});
,but same will create only 1 key locally:
const kvs = await Actor.openKeyValueStore('keyTest');
await kvs.setValue('INPUT', { key: 'value'});
await kvs.setValue('INPUT.json', { key: 'value2'});
Benefits of using suffixes in the storage client:
- DX when working manually with the files
Benefits of allowing files without a suffix:
- Backwards compatibility
- ?
Metadata
Metadata
Assignees
Labels
t-toolingIssues with this label are in the ownership of the tooling team.Issues with this label are in the ownership of the tooling team.