Manual talk:User properties table

Possible values

Where are the possible values for up_property? Emijrp 13:33, 9 January 2012 (UTC)

Those listed in Manual:$wgDefaultUserOptions. Examples: gender, rememberpassword, watchcreations. That is now part of the page. --88.130.114.181 15:43, 15 January 2014 (UTC)

Does it make sense to delete default or invalid preferences?

Just one example from Wikipedia:

[enwiki]> select up_value, count(up_value) from user_properties where up_property = 'skin' group by up_value;
+-------------+-----------------+
| up_value    | count(up_value) |
+-------------+-----------------+
|             |         7180008 |
| 0           |           53977 |
| 1           |            1754 |
| 2           |            3056 |
| amethyst    |            1290 |
| chick       |           31861 |
| cologneblue |           86625 |
| minerva     |             105 |
| modern      |           80541 |
| monobook    |         2190517 |
| myskin      |           16178 |
| nostalgia   |           21144 |
| simple      |           14116 |
| standard    |           34181 |
| vector      |          162403 |
+-------------+-----------------+
15 rows in set (42.87 sec)

I can understand "monobook", "modern", and "cologneblue", but:

• Is it in any way useful to have 162403 rows with the "vector" value, which is default?
• Is it in any way useful to have rows for "chick", "amethyst", and "nostalgia", which are unlikely to ever come back?
• What are the empty string values doing?
• What are the number values?

Another example is the Math properties, which I reported at T166369.

Is there any reason not to clean such things up somehow? Or is it just hassle with no benefit? --Amir E. Aharoni (talk) 20:56, 28 May 2017 (UTC)

This should probably be reported on phabricator, not here, but anyway... Data storage is cheap. The amount of bytes those values represent on the database is negligible. However, doing a database update to change those values massively (which will affect millions of rows) would have a high impact in the database. Is useful to have those values? no. Is useful to fix them? probably not compared to the benefit of fixing them, --Ciencia Al Poder (talk) 21:27, 28 May 2017 (UTC)

It's a discussion, not a request (yet) :)

Storage space is cheap, of course, but still, I can think of some benefits:

• When analyzing people's usage of different features, there's less noise to filter out. (Analyzing the usage of preferences is useful to product managers, designers, etc.)
• Less wondering about what will happen when an invalid or outdated option will have to be processed.
• Reducing the chance that people who have explicitly defined something that should have been default, will stay with the current option when the default changes. For example, if the default skin will change in the future, what will happen to the people who have "vector" defined explicitly?

But still, maybe there are problems that I'm failing to see? --Amir E. Aharoni (talk) 21:39, 28 May 2017 (UTC)

The only problem is doing the modification in production database to fix this data. Someone would need to create a maintenance script that does the modifications in small batches and waiting for replication slave lag. It's not a simple delete from user_properties where up_property = 'skin' and up_value in ('', '0', '1', '2' ...); --Ciencia Al Poder (talk) 09:24, 29 May 2017 (UTC)

Yeah, I know. Anything else? --Amir E. Aharoni (talk) 09:30, 29 May 2017 (UTC)

See previous drama, https://phabricator.wikimedia.org/T54778 & https://phabricator.wikimedia.org/T54777. Probably can't be done until the table has a primary key (https://phabricator.wikimedia.org/T54777). 21:56, 11 June 2017 (UTC)~