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
When removing a field from an object that is stored in database, a good practice is to do it progressively through the versions: version X still reads and writes that field, version X+1 no longer reads that field but keeps on writing it to ensure compatibility with the version X that's still here (continuous deployment) and version X+2 no longer reads nor writes that field. When starting such a process, a script could be created to remove the field from the database when version X+2 is released and thus there is a need to declare that this script should be executed on a particular Datamaintain execution (that occurs to be the one happening on version X+2 release).
How to implement that workflow?
Multiple propositions were done:
Counting Datamaintain executions. The script is to be played in N executions, a counter is stored and decreased each execution until it becomes null and at that moment, the script is run. This proposition is based on the hypothesis that one release means one Datamaintain execution, which isn't always true (see Workflow before/stop/after sample #99) and thus does not seem to be a good choice.
Respect a convention to name the scripts, in order to add a dependency on a script that was played before
No choice has been made yet, this issue aims to give all the propositions found by the maintainer team and to allow discussion in order to find the best solution.
The text was updated successfully, but these errors were encountered:
Why such a workflow?
When removing a field from an object that is stored in database, a good practice is to do it progressively through the versions: version X still reads and writes that field, version X+1 no longer reads that field but keeps on writing it to ensure compatibility with the version X that's still here (continuous deployment) and version X+2 no longer reads nor writes that field. When starting such a process, a script could be created to remove the field from the database when version X+2 is released and thus there is a need to declare that this script should be executed on a particular Datamaintain execution (that occurs to be the one happening on version X+2 release).
How to implement that workflow?
Multiple propositions were done:
executionId
(see Add datamaintain execution id in configuration #100)No choice has been made yet, this issue aims to give all the propositions found by the maintainer team and to allow discussion in order to find the best solution.
The text was updated successfully, but these errors were encountered: