Skip to content

Re-consider design choices of KVS local storage client #515

@Pijukatel

Description

@Pijukatel

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:

  1. On the file system, there is a pre-existing file someKey.bin
    Possible interpretations:
  • It is a key: someKey and its value is of type bytes
  • It is a key: someKey.bin and its value is of type bytes
    The local client has to guess and pick one of those options
  1. 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

No one assigned

    Labels

    t-toolingIssues with this label are in the ownership of the tooling team.

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions