Refactor account storage inspection

Question

Refactor account storage inspection

Closed this issue a year ago · 17 comments

Refactor account storage inspection to start using Cadence script to iterate over account storage and return the data https://developers.flow.com/cadence/language/accounts

Although we should discuss whether we should keep the implementation for private storage since that isn't exposed with Cadence Account methods.

Answer 1 · 2022-11-22T19:49:23.000Z

private storage ? you mean the links ? I think it is exposed vie enumeration API.

Answer 2 · 2022-11-23T18:00:38.000Z

Sorry I mean private paths.

Answer 3 · 2023-01-18T08:30:15.000Z

I can take this; I have experience to get storage via Account API while making https://f.dnz.dev

Answer 4 · 2023-01-18T09:55:02.000Z

That would be good. I'm a bit on the fence with this since if it's natively now supported using Cadence script does it make sense to have an API for it on the emulator, but at the same time I can see the advantage of having this kind of APIs available for ease of development, so inspection API in a sense. What is your opinion @bluesign?

Answer 5 · 2023-01-18T11:59:13.000Z

Both has some cons and pros; in ideal world, fvm would expose this.

Basically using cadence and fvm internals, causing juggling, on the other hand; if later we want to modify storage etc for example, current code will be required. It is a hard call to make. I say if we will just expose storage, let's convert to script; if we have other features planned, we keep it like this

Answer 6 · 2023-01-18T13:31:52.000Z

I'm all up for using the script. The thing I wonder more is, should we even have any kind of API for this. I feel it's good idea for now to keep it since developers will have an easy way to use it to check storage, but I want to soon have some kind of utilities supported in SDKs that will allow this kind of actions easily.

Answer 7 · 2023-01-18T13:35:20.000Z

This also depends on future plans, I think if we will not have any editing ability, it is obsolete now to have API for storage. Burden to maintain is really high. Also I am not sure if there is any user of this API.

Answer 8 · 2023-01-18T13:39:59.000Z

I know currently flowser team is using the API for storage.

Are you proposing completely removing the API? or just switching API to use a script call internally?

Answer 9 · 2023-01-18T13:44:53.000Z

I am very warm to SDK has to implement that part idea as we don't plan editing, I would vote to remove the API. Script to get all storage is very minimal, if needed I can assist Flowser team on that too.

Also making it script call internally and deprecating the API is also an option.

Answer 10 · 2023-01-18T14:19:08.000Z

Yeah, no worries I can help with the script.

I agree it might be good to just remove this to not over bloat the codebase.

Answer 11 · 2023-01-20T19:34:12.000Z

should I make a PR to remove this API ? or we hold for sometime ?

Answer 12 · 2023-01-23T08:32:51.000Z

should I make a PR to remove this API ? or we hold for sometime ?

Let's mark it as deprecated first, but it would be good to share a link to a document showing how you can iterate over storage which is currently missing on our docs :/

Answer 13 · 2023-01-23T09:00:08.000Z

that's a great idea, I think cadence has some documents on this, but nothing to run easily.

Answer 14 · 2023-01-23T09:14:14.000Z

Yeah that's more as a spec. Let me talk with the team.

Answer 15 · 2023-01-24T14:45:38.000Z

@sideninja I think we can keep this I guess, when building debugger ( #294 ) I figured out there when showing storage it is pretty useful.

Answer 16 · 2023-01-24T14:47:50.000Z

I think keeping storage accessible will be useful for sure in the future, I can think of many interesting features, but I would say we should remove the HTTP API

Answer 17 · 2023-01-24T14:49:26.000Z

ah yeah, I mentioned about keeping code, API we can retire for sure.