[1r] DB migrations refactor#9
Conversation
Move EventUtils.bs.js relationship
|
@JasoonS something has changed with the pipeline here... it's breaking pretty early in the workflow. |
DZakh
left a comment
DZakh
left a comment
There was a problem hiding this comment.
Looks good! Also, the CI should work correctly now, after Jason updated secrets.
| {{/each}} | ||
| }) | ||
|
|
||
| let rowsSchema = S.array({{entity.name.uncapitalized}}EntitySchema) |
There was a problem hiding this comment.
| let rowsSchema = S.array({{entity.name.uncapitalized}}EntitySchema) | |
| let rowsSchema = S.array(schema) |
There was a problem hiding this comment.
Nice! I actually fixed this in the PR stacked above this. I didn't pick it up here because this was not being used until I connected it.
I think if you're happy with taking the commit from the stacked pr then rather do that to avoid conflicts
| type row = { | ||
| {{#each entity.params as | param |}} | ||
| {{#unless param.is_derived_from }}{{param.field_name.uncapitalized}}{{#if param.is_entity_field}}_id{{/if}}: {{param.type_rescript}},{{/unless}} | ||
| {{/each}} | ||
| } | ||
|
|
||
| let schema = S.object((. s) => { | ||
| {{#each entity.params as | param |}} | ||
| {{#unless param.is_derived_from }}{{param.field_name.uncapitalized}}{{#if param.is_entity_field}}_id{{/if}}: s.field("{{param.field_name.uncapitalized}}{{#if param.is_entity_field}}_id{{/if}}", {{param.type_rescript_schema}}),{{/unless}} | ||
| {{/each}} | ||
| }) |
There was a problem hiding this comment.
I have a feeling that it might be better to create the type, schemas, and other entity elements on the Rust side.
There was a problem hiding this comment.
Yes I agree! I think we should migrate those changes we made on the fuel indexer to evm. It's much nicer. And will be more powerful for nested structs (right now we just inline nested structs as tuples instead of providing a record type for them)
| {{entity.name.capitalized}}.table, | ||
| {{/each}} | ||
| ] | ||
| let schema = Schema.make(allTables) |
There was a problem hiding this comment.
A little bit confusing to have it the same name as rescript-schema
There was a problem hiding this comment.
Ah good point 👍🏼 we can change the name. Any suggestion for a name? This module is meant to coordinate relationships between entity tables as defined in the graphql schema
There was a problem hiding this comment.
Also does it override namespace for rescript schema or not?
There was a problem hiding this comment.
Also does it override namespace for rescript schema or not?
No, it's not.
This module is meant to coordinate relationships between entity tables as defined in the graphql schema
dbSchema maybe?
There was a problem hiding this comment.
Ok cool, lets do DbSchema but I will change in my next PR not here 👍🏼
2 participants
First step of remodelling db interaction to be more composable and modular
Tables are now defined in a rescript structure.
Migrations are derived from the rescript structure
The model should be more composable and less hidden behind codegen logic. I decided it's ok for Migration queries to be composed with sql.unsafe since we don't need any prepared statements or injection protection. For the next step which is creating composeable read/write/delete queries these will use dynamic queries which do have prepared statements and injection protection.
Next steps
Hasura tracking via table structure
DbFunctions composed via new "Table" model
All in memory store interaction, serializers/deserializers and stores created via table structure
Trying to offload generated code and make more static to make parts moduler.