Open sybrenstuvel opened 6 years ago
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:
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).
The credentials for the database are configurable in
secrets/fragmenta.json
. However, the default migrations indb/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 inxxxx-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 fromxxx-Create-Tables.sql
.Of course this requires the database connection to be made with the correct credentials, which might not be the case (see https://github.com/fragmenta/fragmenta/issues/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.