Database migration scripts "squashed" from many scripts into two main sections, migration scripts (schema) and seed scripts (data)
Seed divided into two sections, one as a "true" seed (metadata) and another as an extra seed (data necessary for the build to pass)
Remove migration module as it is no longer needed
How to add new metadata to db via seed
15m
toggle PR
Chongsun
Introduction of feature toggle mechanism in build process
Use of feature toggle mechanism to toggle off various UI components for 2.0 release
10m
seed/demo
Chongsun
Create more robust seed data with which to demo
Possibly determine a process in updating demo seed scripts
Discussion of seed and test seed scripts
Notes
Nothing further on git-repo. Merge it.
On consolidation and seed:
migration module removed
data, e.g. rights, are needed for the functioning of the program (outside of build), and those are managed by flyway
there is "starter seed" and "extra seed". The latter meaning seed data for the integration tests to pass, which are needed for build to complete. Starter seed is for data used in standing up a new implementation.
some further sorting of seed data between seed type tasks and flyway tasks
Elias Muluneh asked how migration script consolidation was made, Chongsun Ahn (Unlicensed) says it started with a pg_dump and now is updated manually. On pros and cons between pg_dump and concatenating existing scripts - pg_dump would likely know the correct ordering to things.
Elias Muluneh is concerned that a dump that's made today, from v 9.3 e.g. Then in the future applied to a newer version of postgres it may have a different meaning / version inconsistency. Alternative is to concatenate all previous migration scripts into one file. Chongsun Ahn (Unlicensed) to check into this and report back.
Elias Muluneh asked if you can toggle the toggle or if you have to stick with what you chose. Chongsun Ahn (Unlicensed) points us to custom_seed where these features are toggled on and off, Josh Zamor points out it's right based and so it's possible to change. Elias Muluneh asks if there is a better name for this as "seed" is over-used. To all: We need a new name!
Chongsun Ahn (Unlicensed) looking for a new seed task for demo data as testSeed is bloated. Looking at the data-set that Ron created (the Manitoba scenario). Looking at creating a task for "demo" data. This is tricky, looking at a diff from seed to demoSeed.... gradle setupDb seed build to gradle setupDb baseseed demoseed run would be needed to build and standup a demo environment from a gradle task.
Elias Muluneh suggests Navicat for data diffs (commercial so out of band from project)
Rich Magnuson (Deactivated) points out that we have some more sonar and jenkins tasks for completing 2.0. Also we'd like to do some regression testing if anyone has any manual or automated set of tests.
We do still think it's worth it to update Sonar, though a bit pressed for time
Action items
Everyone to make a new name for custom_seed. Crowdsource!
Just call it for what it is: "restore_deactive_featureset.sql"