Snapshot with dependencies

jamie commented

2017-02-15 22:31:26 +00:00

(Migrated from git.hazaar.io)

I'm getting into a bit of trouble with the order in which things are being deposited into the migration file.

For example, a snapshot I just produced created the constraints array BEFORE the tables array because a table that was processed was not new and only had a column change. This causes an 'alter' section to be created, not a table section. Then constraints were processed on the table, creating the 'table' section. Then finally the tables were processed creating the 'tables' section.

When we run the migrate replay, everything is done in the order in which it exists in the file. This is on purpose so that the order can be defined specifically. However, because the snapshot messed things up, constraints were attempted to be created on tables that did not yet exist.

This will be fixed in stages.

Stage 1

Define a specific order in the $changes array. So do 'drop' first, which removed things such as constraints and tables. Then 'alter' next. Then 'create' using the order of 'tables', 'constraints', 'indexes'.

Stage 2

We will need some form of intelligent dependency management. That way we can generate a migration file that will replay things in the correct order. So if we are creating a constraint, we can be assured that the table it is referencing has been created.

I'm getting into a bit of trouble with the order in which things are being deposited into the migration file. For example, a snapshot I just produced created the constraints array BEFORE the tables array because a table that was processed was not new and only had a column change. This causes an 'alter' section to be created, not a table section. Then constraints were processed on the table, creating the 'table' section. Then finally the tables were processed creating the 'tables' section. When we run the migrate replay, everything is done in the order in which it exists in the file. This is on purpose so that the order can be defined specifically. However, because the snapshot messed things up, constraints were attempted to be created on tables that did not yet exist. This will be fixed in stages. ## Stage 1 Define a specific order in the ```$changes``` array. So do 'drop' first, which removed things such as constraints and tables. Then 'alter' next. Then 'create' using the order of 'tables', 'constraints', 'indexes'. ## Stage 2 We will need some form of intelligent dependency management. That way we can generate a migration file that will replay things in the correct order. So if we are creating a constraint, we can be assured that the table it is referencing has been created.

jamie commented

2017-04-01 00:07:00 +00:00

(Migrated from git.hazaar.io)

added ~160 label

jamie commented

2017-07-25 02:35:21 +00:00

(Migrated from git.hazaar.io)

removed ~160 label

jamie commented

2017-07-28 03:13:25 +00:00

(Migrated from git.hazaar.io)

assigned to @jamie

jamie commented

2019-01-30 01:05:42 +00:00

(Migrated from git.hazaar.io)

mentioned in issue #27

jamie commented

2019-01-30 02:04:52 +00:00

(Migrated from git.hazaar.io)

created merge request !6 to address this issue

jamie commented

2019-01-30 02:04:53 +00:00

(Migrated from git.hazaar.io)

mentioned in merge request !6

jamie commented

2019-01-30 02:09:36 +00:00

(Migrated from git.hazaar.io)

This has completely changed. The $changes is being completely defined upfront now, but it's layout has changed slightly. Instead of the sequence being mode->action->type it is now mode->type->action. This means that all table actions are performed first, then all constraint actions, followed by index, view and functions. This is in line with the way the whole schema file operates and makes more sense.

Because this is a change to the layout of a schema migration file, I have added a version attribute. If this does not exist, then the version is 1. Version 2 is this new version and we loop through the migration actions in a slightly different way. Things should work as they did previously as there were no changes to the actual action execution code, just the order in which the migration sections are processed. It will still be possible to process version 1 migration scripts going forward so there is no need for developers to update old scripts.

This has completely changed. The `$changes` is being completely defined upfront now, but it's layout has changed slightly. Instead of the sequence being `mode->action->type` it is now `mode->type->action`. This means that all table actions are performed first, then all constraint actions, followed by index, view and functions. This is in line with the way the whole schema file operates and makes more sense. Because this is a change to the layout of a schema migration file, I have added a `version` attribute. If this does not exist, then the version is `1`. Version `2` is this new version and we loop through the migration actions in a slightly different way. Things should work as they did previously as there were no changes to the actual action execution code, just the order in which the migration sections are processed. It will still be possible to process version 1 migration scripts going forward so there is no need for developers to update old scripts.

jamie commented

2019-01-30 02:11:16 +00:00

(Migrated from git.hazaar.io)

mentioned in commit 054068652d

mentioned in commit 054068652dac308104f5ff77aeb338e2a093a2cc

jamie commented

2019-01-30 02:17:34 +00:00

(Migrated from git.hazaar.io)

mentioned in commit daa54ece4a

mentioned in commit daa54ece4a2bbc693e0488de448e41ed50b66ee4

jamie commented

2019-01-30 02:17:34 +00:00

(Migrated from git.hazaar.io)

closed via merge request !6

jamie commented

2019-01-30 02:17:34 +00:00

(Migrated from git.hazaar.io)

closed via commit 054068652d

closed via commit 054068652dac308104f5ff77aeb338e2a093a2cc

Rows
Columns

Snapshot with dependencies #11

Stage 1

Stage 2