Refactor #15866
openProvide alternative way of migrating data as oposed misuing db:migrate for this purpose
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.
Updated by Ivan Necas over 8 years ago
- Related to Bug #15655: [upgrade] db migrate failed with error: undefined local variable or method `openscap_proxy_id' added
Updated by Ivan Necas over 8 years ago
- Related to Bug #15040: Could not find table 'users' during db:migrate added
Updated by Ivan Necas over 8 years ago
- Related to Bug #14468: --foreman-unattended breaks db:migrate added
Updated by Ivan Necas over 8 years ago
- Related to Bug #14410: Failure to run DB migrations prevents plugin permissions being loaded added
Updated by Ivan Necas over 8 years ago
- Related to Refactor #15200: db migrations should not be used to modify external databases added
Updated by Ivan Necas over 8 years ago
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.
Updated by Ivan Necas over 8 years ago
- Related to Bug #14983: Faking host and other models with STI in migrations doesn't work due to STI added
Updated by Ivan Necas over 8 years ago
Another example of consequences from the current way we do migrations https://bugzilla.redhat.com/show_bug.cgi?id=1360707
Updated by Marek Hulán over 8 years ago
- Related to Bug #15920: migration CopyUnmanagedHostsToInterfaces may fail on interface conversations when ipv6 migration has not occurred added