Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix/reschedule in n days affects manually rescheduled cards #422

Merged
merged 2 commits into from
Jun 14, 2024
Merged

Fix/reschedule in n days affects manually rescheduled cards #422

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
e51d926
Fix/reschedule in n days affects manually rescheduled cards
L-M-Sherlock Jun 12, 2024
21f378a
format
L-M-Sherlock Jun 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 10 additions & 3 deletions schedule/reschedule.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -66,6 +66,7 @@ def set_load_balance(self, did_query=None):
f"""SELECT (id/1000-{mw.col.sched.day_cutoff})/86400, count(distinct cid)
FROM revlog
WHERE ease > 0
AND (type < 3 OR factor != 0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this change required?

If I am not wrong, this code is for calculating the number of reviews done in the past. I don't think that we should exclude the cram revlogs here. Irrespective of whether they are used to reschedule the card or not, they are actual reviews and take up study time just like other reviews do.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think cramming is out of plan. Should we consider it in load balance?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Forget about that for a moment.

Can you first tell me why are calculating the number of reviews done in the past? Load balancing works for future days and not for past days, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we need to calculate the size of backlog. If the size of backlog is less than the average, some cards will be rescheduled to today.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, do you mean that the past reviews are used to calculate the average? And then, if today's due count is less than the past average, some reviews would be brought forward (aka advanced) from the future.

If so, I agree that the cram reviews shouldn't be used to calculate the average.

By the way, the code is quite complicated. It would be helpful to add some comments explaining the purpose of some of the codes.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For example, if the size of backlog plus the number of due cards is 100, and the number of due cards tomorrow is 150, some cards due tomorrow will be rescheduled to today.

GROUP BY (id/1000-{mw.col.sched.day_cutoff})/86400"""
)
}
Expand Down Expand Up @@ -232,9 +233,15 @@ def reschedule_background(
if recent:
today_cutoff = mw.col.sched.day_cutoff
day_before_cutoff = today_cutoff - (config.days_to_reschedule + 1) * 86400
recent_query = (
f"AND id IN (SELECT cid FROM revlog WHERE id >= {day_before_cutoff * 1000})"
)
recent_query = f"""AND id IN
(
SELECT cid
FROM revlog
WHERE id >= {day_before_cutoff * 1000}
AND ease > 0
AND (type < 3 OR factor != 0)
)
"""

if filter_flag:
filter_query = f"AND id IN {ids2str(filtered_cids)}"
Expand Down
Loading