You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on May 9, 2022. It is now read-only.
The user progress histogram on the My Progress page is currently not a reliable indicator of behaviour:
It is very easy to make it look impressive by answering the same question incorrectly hundreds of times. It also hits the log events table, which is perilously slow sometimes.
We can move to using the question attempts table, and only showing unique correct attempts. This gives a much more reliable indication of activity and cannot be cheated easily.
WITH first_correct_attempts AS
(SELECT question_id, min(timestamp) AStimestampFROM question_attempts WHERE user_id=? AND correct GROUP BY question_id)
SELECT to_char(gen_month, 'YYYY-MM-01'), count(question_id)
FROM generate_series(date_trunc('month', ?::timestamp), ?, INTERVAL '1' MONTH) m(gen_month)
LEFT OUTER JOIN first_correct_attempts ON ( date_trunc('month', timestamp) = date_trunc('month', gen_month) )
GROUP BY gen_month
ORDER BY gen_month ASC;
This will benefit from an additional index on the question_attempts table:
CREATEINDEXquestion_attempt_timestampONpublic.question_attempts USING btree ("timestamp");
I'm unsure where this should go in the API though, presumably the QuestionManager, rather than the LogManager that is currently used?
The text was updated successfully, but these errors were encountered:
The user progress histogram on the My Progress page is currently not a reliable indicator of behaviour:

It is very easy to make it look impressive by answering the same question incorrectly hundreds of times. It also hits the log events table, which is perilously slow sometimes.
We can move to using the question attempts table, and only showing unique correct attempts. This gives a much more reliable indication of activity and cannot be cheated easily.
This will benefit from an additional index on the question_attempts table:
I'm unsure where this should go in the API though, presumably the QuestionManager, rather than the LogManager that is currently used?
The text was updated successfully, but these errors were encountered: