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
The issue: The schema in the definitions might change but there isn't a standard way to deal with keeping the document in line with updates to the schema.
The idea is to add a migrate function and version field to the NoCodeComponentDefinition object. The migrate function would be called (probably when reading a document from the backend) and would run migrations in order based on the current version of the definition and the version of the data that is stored in the document to bring the document up to the latest version.
This would allow for document schemas to change over time with the developer able to implement migration steps that automatically deal with the documents as they are read instead of having to build a bulk migration process that is run on deployment.
Some examples of when this would be utilised:
renaming a field
moving a few fields (e.g. select fields) into a widget that has them all combined into one object
changing the type of the field e.g. number to select
The text was updated successfully, but these errors were encountered:
That would be great. The simplest way I see it is like this:
exportconstlinkDefinition: NoCodeComponentDefinition={// ...version: 2,migrations: [// index 0 is migration from 0 -> 1(entry0: NoCodeComponentEntry)=>{constentry1 : NoCodeComponentEntry=migrateEntryFrom0To1(entry0);returnentry1},// index 1 is migration from 1 -> 2(entry1: NoCodeComponentEntry)=>{constentry2 : NoCodeComponentEntry=migrateEntryFrom1To2(entry1);returnentry2}]};
The issue: The schema in the definitions might change but there isn't a standard way to deal with keeping the document in line with updates to the schema.
The idea is to add a migrate function and version field to the NoCodeComponentDefinition object. The migrate function would be called (probably when reading a document from the backend) and would run migrations in order based on the current version of the definition and the version of the data that is stored in the document to bring the document up to the latest version.
This would allow for document schemas to change over time with the developer able to implement migration steps that automatically deal with the documents as they are read instead of having to build a bulk migration process that is run on deployment.
Some examples of when this would be utilised:
The text was updated successfully, but these errors were encountered: