Change Details

==== Background The Growth team is soon going to start working on mentor dashboard. This dashboard would likely contain some data about mentees assigned to a particular mentor (or metadata about mentees in general). Doing such stuff probably would require filtering user_properties based on `up_value` (a blob), which sounds like a bad idea to do. Example query to find number of mentees assigned to each mentor: ```lang=SQL ``` ==== Proposed solution Create `growthexperiments_mentees` table (or similar), and store mentor/mentee relationship there, rather than `user_properties`. This new table could have `mentor_id, mentee_id` as a composite index, which would make querying This would also make it possible to expose the

==== Background The Growth team is soon going to start working on mentor dashboard. This dashboard would likely contain some data about mentees assigned to a particular mentor (or metadata about mentees in general). Doing such stuff probably would require filtering user_properties based on `up_value` (a blob), which sounds like a bad idea to do. Example query to find number of mentees assigned to each mentor: ```lang=SQL SELECT user_name, COUNT(*) FROM user_properties JOIN user ON up_value=user_id WHERE up_property="growthexperiments-mentor-id" GROUP BY user_id ORDER BY COUNT(*) DESC; ``` ==== Proposed solution Create `growthexperiments_mentees` table (or similar), and store mentor/mentee relationship there, rather than `user_properties`. This new table could have `mentor_id, mentee_id` as a composite index, which would mean queries like the one above would be just an index scan. Completing this task would also make it possible to expose the mentor/mentee relationship easily to Toolforge replicas, where communities could do their own work around it. That could show us which features are actually used by wikis, and which could be implemented back to our codebase.

==== Background The Growth team is soon going to start working on mentor dashboard. This dashboard would likely contain some data about mentees assigned to a particular mentor (or metadata about mentees in general). Doing such stuff probably would require filtering user_properties based on `up_value` (a blob), which sounds like a bad idea to do. Example query to find number of mentees assigned to each mentor: ```lang=SQL SELECT user_name, COUNT(*) FROM user_properties JOIN user ON up_value=user_id WHERE up_property="growthexperiments-mentor-id" GROUP BY user_id ORDER BY COUNT(*) DESC; ``` ==== Proposed solution Create `growthexperiments_mentees` table (or similar), and store mentor/mentee relationship there, rather than `user_properties`. This new table could have `mentor_id, mentee_id` as a composite index, which would make queryean queries like the one above would be just an index scan. Completing Thisthis task would also make it possible to expose the mentor/mentee relationship easily to Toolforge replicas, where communities could do their own work around it. That could show us which features are actually used by wikis, and which could be implemented back to our codebase.