Updated solver schemas #74
Conversation
| "required": true, | ||
| "default": "No" | ||
| }, | ||
| "activeNetworks": { |
There was a problem hiding this comment.
Why would we want the activeNetworks and hasActiveNetworks fields if we have the isActive field on the network itself?
There was a problem hiding this comment.
Actually, thinking about this some more I think it makes sense to aggregate these on the solver schema to make it easier to find. Will we use this to show the network names or their addresses? I can see both being useful.
bram-vdberg
left a comment
bram-vdberg
left a comment
There was a problem hiding this comment.
I think the schema changes make sense, I'm not sure about adding automation to the CMS though.
First, it disperses complexity into two areas. We would have some automation take place in Dagster and some in the CMS. This means that in the future updates would require changes in two different repo's. One of the main reasons we set up Dagster was to reduce this and keep all data related automation in one place.
Second, other teams depend on the CMS as well. Adding changes to its function might have unintended consequences. Since this could affect other teams I think it's better to be conservative with regards to changes to the CMS.
I would prefer if we only change the schemas and then make updates to the CMS through Dagster using the CMS API.
This pr updates the solver tables schema and adds lifecycle functions that automatically update certain fields based on data in cms. The fields affected by lifecycle are fields that don't require extra data outside of cms and can be handled without human involvement like the logo field that will be handled by a dagster asset.