You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In the ETL we have an updated cycle that only touches datasets once a year or less often. When writing partial grapher configs there, it is therefore normal for them to be written using an old schema version. The grapher API that the ETL uses to save the grapher configs defined in the ETL should thus be able to accept old versions and transparently update them to the new version wherever possible (usually this means dropping obsolete fields or rewriting renamed enums etc)
The text was updated successfully, but these errors were encountered:
I implemented a very basic version of this in the saveGrapher function in apiRouter.ts because a schema change made us bump to 005 and the ETL still produces 004 schemas in several places.
I felt this might be one I could take a stab at - since the PR @danyx23 and I worked on was complicated by this, so there's little context switching for me.
But maybe it's too much? I would commit to working on this w/c 16-sep if given the go ahead.
In the ETL we have an updated cycle that only touches datasets once a year or less often. When writing partial grapher configs there, it is therefore normal for them to be written using an old schema version. The grapher API that the ETL uses to save the grapher configs defined in the ETL should thus be able to accept old versions and transparently update them to the new version wherever possible (usually this means dropping obsolete fields or rewriting renamed enums etc)
The text was updated successfully, but these errors were encountered: