Change Details

Hi, we'd like to have our new extension's table reviewed. * The schema: https://phabricator.wikimedia.org/diffusion/EGPR/browse/master/sql/tables.sql * Where to run those changes: on a central database, `centralauth` sounds most suitable, though we're open to other suggestions. Our table even references a CentralAuth table though there are currently no joins that use that. * When to run those changes: whenever ready * Whether the schema change is backwards compatible: new extension * Whether the schema change has been tested already on some of the test/beta wikis: can be tested on Vagrant or http://commtech.wmflabs.org/wiki/Main_Page * Whether the data should be available on labs replicas: just like `user_properties`, this data is private. Just like that table we can expose rows with `gp_property='gender'`. * Predicted usage: ** Say 10k regular users * 10 preferences each * 10 just in case = 1M rows on `centralauth.global_preferences`. ** For local preference overrides, rows are added to local wikis' `user_properties` tables. Say, 20% of users would want to override a couple of settings - that would be up to 400k rows across all SUL wikis.

Hi, we'd like to have our new extension's table reviewed. * The schema: https://phabricator.wikimedia.org/diffusion/EGPR/browse/master/sql/tables.sql * Where to run those changes: on a central database, `centralauth` sounds most suitable, though we're open to other suggestions. Our table even references a CentralAuth table though there are currently no joins that use that. * When to run those changes: after the extension's deployment has been agreed upon. * Whether the schema change is backwards compatible: new extension * Whether the schema change has been tested already on some of the test/beta wikis: can be tested on Vagrant or http://commtech.wmflabs.org/wiki/Main_Page * Whether the data should be available on labs replicas: just like `user_properties`, this data is private. Just like that table we can expose rows with `gp_property='gender'`. * Predicted usage: ** Say 10k regular users * 10 preferences each * 10 just in case = 1M rows on `centralauth.global_preferences`. ** For local preference overrides, rows are added to local wikis' `user_properties` tables. Say, 20% of users would want to override a couple of settings - that would be up to 400k rows across all SUL wikis.

Hi, we'd like to have our new extension's table reviewed. * The schema: https://phabricator.wikimedia.org/diffusion/EGPR/browse/master/sql/tables.sql * Where to run those changes: on a central database, `centralauth` sounds most suitable, though we're open to other suggestions. Our table even references a CentralAuth table though there are currently no joins that use that. * When to run those changes: whenever readyafter the extension's deployment has been agreed upon. * Whether the schema change is backwards compatible: new extension * Whether the schema change has been tested already on some of the test/beta wikis: can be tested on Vagrant or http://commtech.wmflabs.org/wiki/Main_Page * Whether the data should be available on labs replicas: just like `user_properties`, this data is private. Just like that table we can expose rows with `gp_property='gender'`. * Predicted usage: ** Say 10k regular users * 10 preferences each * 10 just in case = 1M rows on `centralauth.global_preferences`. ** For local preference overrides, rows are added to local wikis' `user_properties` tables. Say, 20% of users would want to override a couple of settings - that would be up to 400k rows across all SUL wikis.