feat: add support for key schemas #480
Conversation
|
Adding metadata to the schema table pushes the World contract over the contract size limit, which I'm addressing in my next PR, so gonna leave this change for then. |
|
ooc is the world only doing the minimal necessary to bootstrap? It’s not registering userland schemas and systems etc right? That’s done via deploy script? |
Correct, the World only sets up its own internal tables (and soon internal systems) |
packages/store/src/StoreCore.sol
Outdated
| registerSchema(StoreCoreInternal.SCHEMA_TABLE, SchemaLib.encode(SchemaType.BYTES32)); | ||
| registerSchema( | ||
| StoreCoreInternal.SCHEMA_TABLE, | ||
| SchemaLib.encode(SchemaType.BYTES32, SchemaType.BYTES32), |
There was a problem hiding this comment.
I think the first BYTES32 is supposed to be padding for keys now.
If so this took me a while to understand despite knowing how this all works pretty well, a comment would be useful
There was a problem hiding this comment.
The first BYTES32 is the valueSchema, the second BYTES32 is the keySchema. Will add a comment. Also wanna turn the SchemaTable into an autogenerated table at some point, but there might be circular dependencies with the schema existing...
There was a problem hiding this comment.
The first BYTES32 is the valueSchema, the second BYTES32 is the keySchema
right that makes more sense, it's not just padding. What's the UINT256 one then?
There was a problem hiding this comment.
That's the Schema table's single primary key, which has type UINT256 because it represents a tableId. Added a comment about that too.
StoreSetRecordevent (and always typedbytes32).Store,WorldandCLI(tablegen + deploy):{ valueSchema: Bytes32, keySchema: Bytes32 }(used to be just{ schema: Bytes32 })