Refactor #15866
open
Provide alternative way of migrating data as oposed misuing db:migrate for this purpose
Added by Ivan Necas over 8 years ago.
Updated over 6 years ago.
Description
In couple of years, we hit quite a lot issues that were related to the fact that we
perform data manipulation in db:migration. This issues include:
1. problems with relying on columns in data that were added at the same run
and not being populated yet
2. problems with external systems needed to be ready as part of the data migration
The issue becomes even more visible when the migrations are run with more plugins
installed.
The goal for this issue is to find a better way to organize our data migrations
that would prevent us from hitting the issues we did in the past.
- Related to Bug #15655: [upgrade] db migrate failed with error: undefined local variable or method `openscap_proxy_id' added
- Related to Bug #15040: Could not find table 'users' during db:migrate added
- Related to Bug #14468: --foreman-unattended breaks db:migrate added
- Related to Bug #14410: Failure to run DB migrations prevents plugin permissions being loaded added
- Related to Refactor #15200: db migrations should not be used to modify external databases added
I just did a simple search db DB migrate issues in redmine at added few that are a direct consequence
of the way we do the data migrations right now.
- Related to Bug #14983: Faking host and other models with STI in migrations doesn't work due to STI added
- Bugzilla link set to 1361676
- Related to Bug #15920: migration CopyUnmanagedHostsToInterfaces may fail on interface conversations when ipv6 migration has not occurred added
Also available in: Atom
PDF