Actions
Refactor #15866
open
Provide alternative way of migrating data as oposed misuing db:migrate for this purpose
Status:
New
Priority:
Normal
Assignee:
-
Category:
DB migrations
Target version:
-
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 almost 9 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 almost 9 years ago
- Related to Bug #15040: Could not find table 'users' during db:migrate added
Updated by Ivan Necas almost 9 years ago
- Related to Bug #14468: --foreman-unattended breaks db:migrate added
Updated by Ivan Necas almost 9 years ago
- Related to Bug #14410: Failure to run DB migrations prevents plugin permissions being loaded added
Updated by Ivan Necas almost 9 years ago
- Related to Refactor #15200: db migrations should not be used to modify external databases added
Updated by Ivan Necas almost 9 years ago
- Related to Bug #14983: Faking host and other models with STI in migrations doesn't work due to STI added
Updated by
Updated by Marek Hulán almost 9 years ago
- Related to Bug #15920: migration CopyUnmanagedHostsToInterfaces may fail on interface conversations when ipv6 migration has not occurred added
Actions