Database user is configurable but hard-coded in migrations

[sybrenstuvel]

The credentials for the database are configurable in secrets/fragmenta.json. However, the default migrations in db/migrations/*.sql also contain hard-coded usernames & passwords.

Why not simply create the user and database itself from the info in secrets/fragmenta.json? That would remove the need to have usernames & passwords in xxxx-Create-Database.sql.

When connecting to the database to perform migrations, wouldn't tables already be owned by the creating user? If I'm right in that, all the ALTER TABLE xxx OWNER TO "yyy"; lines can be removed from xxx-Create-Tables.sql.

Of course this requires the database connection to be made with the correct credentials, which might not be the case (see fragmenta/fragmenta#32).

Furthermore, I believe that migrations are files that should be loadable on any installation of the site, while the username/password credentials are installation-specific. This is exacerbated by the fact that test, development, and deploy configurations in secrets/fragmenta.json can be configured to use different usernames. Having those usernames hard-coded in the migration files makes no sense.

[kennygrant]

Having those usernames hard-coded in the migration files makes no sense.

There is only one migration which contains the credentials, which are generated each time an instance of the CMS is generated. This is working as designed as it is part of the bootstrap process, the process itself could be improved/replaced (for a start not using psql binaries), however if you're going to bootstrap from scratch like this you need:

1. To autogenerate migrations with unique user/db names (done based on project name)
2. A user who is not the app db user in order to create the migrations the first time round
3. Unique migrations per installation

I think look again at how the projects are structured by making a new one, and inspect the sql generated, to get a feel for how it works - some of the assumptions above are incorrect and appear to be based on these migrations being hard coded (which they are not), and migrations not being specific to an installation (they usually are).