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.

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

Add card meta for persisting custom scheduling state #2040

Merged
merged 4 commits into from
Sep 2, 2022

Conversation

RumovZ
Copy link
Collaborator

@RumovZ RumovZ commented Aug 31, 2022

Closes #2039.
A welcome opportunity to look into custom scheduling!

RumovZ and others added 4 commits August 30, 2022 22:29
Large values will slow down table scans of the cards table, and it's
easier to be strict now and possibly relax things in the future than
the opposite.
+ default customData to empty if it can't be parsed
@dae
Copy link
Member

dae commented Sep 1, 2022

Thanks Rumo. I've made some minor tweaks - do they work for you?

@RumovZ
Copy link
Collaborator Author

RumovZ commented Sep 1, 2022

Sure!

@dae
Copy link
Member

dae commented Sep 2, 2022

🚀

@dae dae merged commit 31b7464 into ankitects:main Sep 2, 2022
@RumovZ RumovZ deleted the card-meta branch September 2, 2022 06:16
@RumovZ
Copy link
Collaborator Author

RumovZ commented Sep 2, 2022

I just wanted to document customData and realised it might not be very useful in its current implementation. I understand the goal is to facilitate persistent custom variables which will be used for calculating scheduling states. Let's say we have something like this:

const fooFactor = customData.fooFac || 1;
if (states.good.normal?.review) {
  states.good.normal.review.scheduledDays *= fooFactor;
}
customData.fooFac = calculateNewFooFactor(fooFactor); // what's the point?

As the custom variable must be calculated in advance, it cannot take into account the answer rating. But without it, what scheduling variable worth persisting can we possibly calculate?
Shouldn't customData be stored in every member of states, so that we can pick the new one depending on the rating?

Am I missing something?

@dae
Copy link
Member

dae commented Sep 2, 2022

You're right 🤦 I guess we could pack it into the top level of SchedulingState so we don't have to update every enum variant?

@RumovZ
Copy link
Collaborator Author

RumovZ commented Sep 2, 2022

Sounds good, I'll take care of it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support persistent state in custom scheduler code
2 participants