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

feat(cli): user types and route/path separation #454

Merged
merged 22 commits into from
Mar 8, 2023
Merged

Conversation

dk1a
Copy link
Contributor

@dk1a dk1a commented Mar 1, 2023

Codegen gets userTypes, which are a first-class type interchangeable with SchemaType. So far the only userType kind is enums.

The specifics of userTypes config option are still very volatile and will likely change in future PRs.
Enums as primary keys seem pointless, but this paves the way for entities and relational types

Copy link
Member

@alvrs alvrs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to verify my understanding:

  • Currently the only supported type of user type is "Enum"
  • The schema is not impacted by user types, user types are handled as uint8 in field values, and therefore no changes are needed for decoding updates on the indexer or client
  • Currently only the autogenerated Solidity table libraries care about user types (in the function signatures, for encoding/decoding, and for the return type)
  • In a follow up PR we can add autogenerated typescript enums and similar auto-generated wrappers around the client decoders to turn the uint8 values into Enums

Correct?

This is a very useful addition to the autogenerated libraries. You mentioned you expect this to pave the way for foreign keys, could you elaborate a bit on this?

I think we should merge this asap, before #467, because it touches a lot of the same code

packages/cli/foundry.toml Outdated Show resolved Hide resolved
packages/cli/remappings.txt Show resolved Hide resolved
packages/cli/src/config/commonSchemas.ts Outdated Show resolved Hide resolved
packages/cli/src/config/loadStoreConfig.ts Outdated Show resolved Hide resolved
packages/cli/src/config/loadStoreConfig.ts Outdated Show resolved Hide resolved
packages/cli/src/config/loadStoreConfig.ts Outdated Show resolved Hide resolved
packages/cli/src/render-solidity/renderTablesFromConfig.ts Outdated Show resolved Hide resolved
packages/cli/test-contracts-src/tables/Table1.sol Outdated Show resolved Hide resolved
@dk1a
Copy link
Contributor Author

dk1a commented Mar 8, 2023

Currently the only supported type of user type is "Enum"

yes

The schema is not impacted by user types, user types are handled as uint8 in field values, and therefore no changes are needed for decoding updates on the indexer or client

yes

Currently only the autogenerated Solidity table libraries care about user types (in the function signatures, for encoding/decoding, and for the return type)

yes
(I also had to add a little resolver to deploy-2 to get SchemaType from schemaOrUserType)

In a follow up PR we can add autogenerated typescript enums and similar auto-generated wrappers around the client decoders to turn the uint8 values into Enums

yes

This is a very useful addition to the autogenerated libraries. You mentioned you expect this to pave the way for foreign keys, could you elaborate a bit on this?

these aren't strictly sequential things, but the idea is when I make table relationships, user types can be used for:

  • EntityId wrapper like in recs
  • wrapping some primary/foreign key types, allowing them to have instance getters for convenience for example

@alvrs alvrs merged commit 758bf03 into main Mar 8, 2023
@dk1a dk1a deleted the dk1a/tablegen-3 branch May 9, 2023 16:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants