This seems to make sense to me but honestly, I'd probably defer to Dewayne.
In theory, it would be nice if migrations only included "structural" changes (new tables, columns, changing column types or not null, etc) and seeds focused on the "base" (or the minimum required) static data required of TO (types, statuses, roles, etc) and then yea, putting data fixing or data massaging as the last step makes sense to me. But you know what they say about theory... +1 Jeremy On Wed, Jun 7, 2017 at 8:41 AM, Gelinas, Derek <[email protected]> wrote: > I'm adding a feature to traffic ops that creates a new column in > steering_target called type, that is populated with type ids from the type > table. Using admin.pl upgrade, the column is created in migrations, and > the two types for this table are populated by seeds.sql. None of this is > out of the ordinary. Unfortunately I also need to populate the type column > based on data that isn't in there until after seeds.sql is run, so I can't > place this into the migration. Seeds.sql needs to run after the migration > due to any structural changes that happen there. > > Dewayne and I have discussed this a bit this morning, and we're thinking > the best solution might be a third step, run after seeds.sql, called > patches.sql. This would be specifically for data fixes like in this use > case. The order would be as follows: > > migration - structure > seeds - static data > patches - data fixes > > Thoughts? > > Derek
