-
-
Notifications
You must be signed in to change notification settings - Fork 42
Schema Migration Issues
This pages tracks the schema changes made from v5.0.1 (the first version for which we provided upwards migration scripts) to the current release.
##v5.0.2
##v5.1.0
##v5.1.1
##v5.1.2 -no schema changes
##v21.1.0
- adds table flow_expressions
- Table flow_subflows.
-- Adds column sbfl_dgrm_id number not null. -- Adds constraint sbfl_dgrm_id references flow_diagrams.dgrm_id -- data migration - copy dgrm_id from flow_processes.prcs_dgrm_id to all flow_subflows rows in that process sbfl_dgrm_id
- add table flow_flow_event_log
- add table flow_instance_event_log
- add table flow_subflow_event_log
- add table flow_variable_event_log
- Table flow_subflows
-
Add column sbfl_became_current TIMESTAMP WITH TIME ZONE
-
data migration: no need to add / modify data on upgrade
-
Add column sbfl_work_started TIMESTAMP WITH TIME ZONE
-
data migration: no need to add / modify data on upgrade
- add table flow_configuration
-
add V21.1 Config parameters
-
Should the migration script for each new release add any new config parameters added by the release, but leave old ones unchanged? That would suggest we organise the scripts adding the parameters in some sort of structure where there is one file for each release, and the new install just runs all of them - to avoid duplication
- add table flow_messages for error messages
-
do we have 1 file per language, or do we install all languages into all installations?
-
thinking that we delete all messages and then reinsert as part of migration
-
do we need to worry about a customer that dos their own translation & hasn't yet sent us their translations? would be bad to delete by mistake!
-
there is a helper script (currently not pushed into dev) that extracts all messages to create a load script - /helpers/generate_message_loading_file.sql