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

Contracts should be able to report their own schema #152

Open
egasimus opened this issue Mar 2, 2023 · 1 comment
Open

Contracts should be able to report their own schema #152

egasimus opened this issue Mar 2, 2023 · 1 comment
Assignees

Comments

@egasimus
Copy link
Collaborator

egasimus commented Mar 2, 2023

Some trickery may be required to include the results of cosmwasm_schema into the contract. Might be easier to tackle this via the contract macro.

@egasimus egasimus added this to Fadroma Mar 2, 2023
@egasimus egasimus changed the title Contract contains and reports its own schema Contracts should be able to report their own schema Mar 2, 2023
@aakamenov
Copy link
Contributor

As of now it is currently impossible to serialize the schema object into a string. The currently used version of serde_json_wasm in CW 1.1.9 is 0.4.1 which doesn't even support maps. But even when using 0.5.0 which does we run into the dreaded floating point issue. So I can see several options:

  • Wait until enum support in serde_json_wasm just works™ (which might be never not very soon from the looks of it) .
  • Slap together some hack to serialize the schemars object into a valid JSON schema, but:
    • This means that we have to add code to the core crate just to support this.
    • The DSL macro crate becomes dependent on Fadroma.
    • Needs more research into how feasible this even is.
    • It is a hack...
  • Come up with our own format which also has it's problems and downsides:
    • Obviously needs the most thought and work put into it.
    • It needs to be decided whether the format would be human or machine focused. Currently, the interface of a contract can only be inferred by guessing. It would be nice to have a nice and concise human-readable representation which JSON schema is not. On the other hand we want tools to be able to validate it. We will need client-side parsers if that's the case...
    • This introduces our own format and we have require people to derive it for their types (even if it's automatic). We are already doing this for the binary ser/de but I'd argue that the case for that is MUCH stronger than it is for this.

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

No branches or pull requests

2 participants