Last modified: 2014-02-28 13:16:41 UTC
5,169 users have enabled this feature. <-- current 5,169 users have enabled this feature.<-- proposed 7,830 users have tried this feature. Allow users to see how many users total have tried out a beta feature (turned on, then disabled.)
We do not currently have these numbers, will require a schema change.
For more detail: Add a column to the user counts table and just add one to it whenever someone enables a feature. No other computation necessary. You should probably have a conditional SQL statement that sets the initial value to the current value of the people who have it enabled.
If the same user enabled and disabled over and over we'd want this not to affect the "tried" value
Agh. OK, in that case we may need a separate table. I don't like that option, though...updating a different set of counts with yet another job sounds like it would be nasty. I'll +1 that change but I'll want review from someone more tied into performance etc.
Any way we do this, a schema change is needed. My idea: set a "sticky" preference when a user enables a beta feature ("$key-set"), but don't remove it when the user changes the option. Then we just count the number of people with that set and store it in another column in the table. We'd also need a maintenance script to set all the rows for people who currently have a BF turned on (can't get data for people who already turned it off).
(In reply to comment #5) > We'd also need a maintenance script to set all the rows for people who > currently have a BF turned on (can't get data for people who already turned > it off). We could probably retrieve the information from the preference changes EventLogging system if we wanted to…
(In reply to Kunal Mehta (Legoktm) from comment #5) > My idea: set a "sticky" preference when a user enables a beta feature > ("$key-set"), but don't remove it when the user changes the option. Then we > just count the number of people with that set and store it in another column > in the table. When a user enables a beta feature, this feature is added on the 'user_properties' table, but when the user disable that feature, it is not removed from the table, just change its value (up_value) from 1 to 0.. which means that all we have to do is the same we do to count enabled features. Instead of 'where up_value=1' should use 'where up_value=0' on the select command, but I'm not sure if there is a way to take this two values(enabled, disabled) in one select command(with maybe a join) or another way.. > We'd also need a maintenance script to set all the rows for people who > currently have a BF turned on (can't get data for people who already turned > it off). this mean we 'can get data for people who already turned it off'...
can I work on this?
Of course - no need to ask. :) Sharing an early patch on Gerrit for review is welcome!
(In reply to Andre Saboia from comment #7) > (In reply to Kunal Mehta (Legoktm) from comment #5) > > My idea: set a "sticky" preference when a user enables a beta feature > > ("$key-set"), but don't remove it when the user changes the option. Then we > > just count the number of people with that set and store it in another column > > in the table. > > When a user enables a beta feature, this feature is added on the > 'user_properties' table, but when the user disable that feature, it is not > removed from the table, just change its value (up_value) from 1 to 0.. which > means that all we have to do is the same we do to count enabled features. > Instead of 'where up_value=1' should use 'where up_value=0' on the select > command, but I'm not sure if there is a way to take this two values(enabled, > disabled) in one select command(with maybe a join) or another way.. Are you sure that's true? MediaWiki rather aggressively removes unnecessary data from this table, including preference values that are identical to defaults.
(In reply to Bartosz Dziewoński from comment #10) > Are you sure that's true? MediaWiki rather aggressively removes unnecessary > data from this table, including preference values that are identical to > defaults. yeah, now I see.. I'm not sure.. I think, for some reason, this was happening only with the multimedia-viewer extension.
