Change Details

* **database name:** striker * **shard:** m5 * **users:** ** //striker// - application user. Will connect to DB from californium. ** //striker_admin// - admin user. Will connect to DB from terbium and californium. * **grants:** ** `GRANT ALL ON striker.* TO 'striker_admin'@'%'` ** `GRANT SELECT, INSERT, UPDATE, DELETE ON striker.* TO 'striker'@'%'` * **charset:** utf8mb4 * **collation:** utf8mb4_bin ``` CREATE DATABASE striker CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; ``` NOTE: Server will need `innodb_large_prefix` enabled to support UNIQUE indexes on varchar(255) columns with a utf8mb4 encoding Striker will be deployed on californium. As a Labs related service I think that its database should live on the m5 shard. The application currently has 14 tables. Most of them will be tiny (<100 records). There will be a couple of tables that could grow to have a few thousand rows (one tracks Labs user accounts and the other tracks tools). Over the next 12 months additional features will be added which will quite likely add more tables. One desired feature would add tables to describe Tools and track the history of edits to those descriptions. I would be quite surprised if that history table ends up having more than 100,000 records in the near term. As a django app, the framework would really like to manage database schema changes. I'm not a huge fan of that for various reasons, so I think we should make two separate user accounts: one for the application runtime that is granted CRUD rights on the database and a separate admin user that is granted full access to alter the schema. The initial schema can be created using a mysqldump from a testing instance (e.g. striker-dev.commtech.eqiad.wmflabs) with subsequent migrations generated via `manage.py sqlmigrate` and applied manually. I will need access to the striker_admin password to apply these schema changes. I'd also like an opinion on the proper engine (InnoDB?) and default charset (utf8?) to use in a project of this type.

* **database name:** striker * **shard:** m5 * **users:** ** //striker// - application user. Will connect to DB from californium. ** //striker,er_admin// - admin user. striker_adminWill connect to DB from terbium and californium. * **grants:** ** `GRANT ALL ON striker.* TO 'striker_admin'@'%'` ** `GRANT SELECT, INSERT, UPDATE, DELETE ON striker.* TO 'striker'@'%'` * **charset:** utf8mb4 * **collation:** utf8mb4_bin ``` CREATE DATABASE striker CHARACTER SET utf8mb4 COLLATE utf8mb4_bin; ``` NOTE: Server will need `innodb_large_prefix` enabled to support UNIQUE indexes on varchar(255) columns with a utf8mb4 encoding Striker will be deployed on californium. As a Labs related service I think that its database should live on the m5 shard. The application currently has 14 tables. Most of them will be tiny (<100 records). There will be a couple of tables that could grow to have a few thousand rows (one tracks Labs user accounts and the other tracks tools). Over the next 12 months additional features will be added which will quite likely add more tables. One desired feature would add tables to describe Tools and track the history of edits to those descriptions. I would be quite surprised if that history table ends up having more than 100,000 records in the near term. As a django app, the framework would really like to manage database schema changes. I'm not a huge fan of that for various reasons, so I think we should make two separate user accounts: one for the application runtime that is granted CRUD rights on the database and a separate admin user that is granted full access to alter the schema. The initial schema can be created using a mysqldump from a testing instance (e.g. striker-dev.commtech.eqiad.wmflabs) with subsequent migrations generated via `manage.py sqlmigrate` and applied manually. I will need access to the striker_admin password to apply these schema changes. I'd also like an opinion on the proper engine (InnoDB?) and default charset (utf8?) to use in a project of this type.