🖋 script for demo data

[astroash]

Write script to add demo data outlined in #290 to production database

[eliasmalik]

I want to use this as an opportunity to separate seed data from test/demo data. The former is just any data that is necessary for the normal operation of the app (e.g. list of supported disabilities). Test/demo data is any additional data that is required only for testing or demo purposes.

They should be defined separately. I was imagining something like:

database
|- migrations
|- seeds
|- static
|- test_data
|  |- demo_organisation_duplicate_visitors
|  |- demo_organisation_visitor_data
|  |- demo_organisation_volunteer_data
|  |- test_organisations
|  |- test_users
|  |- test_user_roles
|  |- ...
|- util

Here I'm using test_* or demo_* prefixes to distinguish between data used for demo and data used for tests.

We'd then use a command line tool to insert/remove various data sets:

$ db data insert [DATA_SET/FILENAME]
$ db data reset [DATA_SET/FILENAME]

Thoughts?

[astroash]

@eliascodes how do you feel about implementing our own version of migrations for demo data? This would be a nice way to keep track of what demo data has been inserted in to staging/production dbs and make it easier to recreate locally.

[eliasmalik]

Yeah that's a good idea!

[astroash]

@eliascodes can you update this issue with your findings

[eliasmalik]

Steps that I wanted to take:

• [ ] Change everything to typescript
• [ ] Separate directories for test data and demo data
• [ ] Demo data can be attached to any specified CB
• [ ] Refactor various utilities files/functions

I am now less convinced of the usefulness of a data migrations table. Demo data will only be added to junk accounts, which could be identified using #361

What is the benefit of being able to say "we've added demo set A to CB X"?

[astroash]

Migration tables would be beneficial if we end up adding more demo data to demo accounts in the future to support features on new apps. I do not consider demo@ to be a "junk" account if it is used by members of PTC for training purposes.

[eliasmalik]

Migration tables would be beneficial if we end up adding more demo data to demo accounts in the future to support features on new apps

But how exactly?

[astroash]

On reflection, I think you are right.

[eliasmalik]

Tasks outlined in comment should be covered by their own issues.