Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Storage API improvements #376

Open
turbolent opened this issue Sep 16, 2020 · 2 comments
Open

Storage API improvements #376

turbolent opened this issue Sep 16, 2020 · 2 comments
Assignees

Comments

@turbolent
Copy link
Member

turbolent commented Sep 16, 2020

Issue To Be Solved

@MaxStalker pointed out that current storage API has some shortcomings in functionality and usability issues, and proposed several improvements:

  • Overwriting stored values: It should be possible to overwrite storage content. Currently save aborts the program if the target path already stores a value, and a load and destroy is needed to clear the storage path before being able to save.

    Maybe add a fun forceSave<T>(_ value: T, to path: Path) function, which would overwrite storage at the specified location, destroying the resource which is potentially stored

  • Removing stored values: Currently, stored resources can be removed by using the load function and the destroy statement. Value types can not be removed.

    Maybe add a fun clear(_ path: Path) function, which would clear storage at specified location

  • The load, copy, and borrow functions, as well as the capability borrow function, currently return nil both when the storage location is empty, and when the storage location contains a value, but is does not have the requested type. The inability to differentiate the two cases makes debugging hard.

    The function has basically three return value cases:

    1. Nothing is stored
    2. A value is stored, but it does not have the requested type
    3. A value is stored, and it has the requested type

    For case 2:

    • Maybe abort the program, i.e. treat the requested type as a force-cast.
    • Maybe the emulator should log a warning that
  • There is no way to check if there is a value stored for a given location.

    Maybe add a fun type(at path: Path): Type? function, which returns the type of the value stored at the given storage location, if any, and nil otherwise

    Also initializing a storage path in case it is empty is error prone:

     if acct.borrow<&KittyItems.Collection>(from: KittyItems.CollectionStoragePath) == nil {
      acct.save(<-KittyItems.createEmptyCollection(), to: KittyItems.CollectionStoragePath)
    }

    Here, the borrow might fail (return nil) and the save might still error, if the borrow tried to borrow using a different type.

  • Related, functionality to query stored values should be added (see Storage Querying API #208)

@10thfloor
Copy link
Contributor

10thfloor commented Sep 18, 2020

Should we split this into separate issues?

@turbolent
Copy link
Member Author

@10thfloor Definitely, for now it's basically just a place to gather potential improvements, but once it's well defined we can make it an epic, and then should/will create individual issues for each of the items!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants