- cramming is now a separate scheduler type
- correctly answering a card while cramming causes its scheduling to be
changed in the standard review too
- options to sort cards by earliest modified, ordered, random
- render priority 0 obsolete, as it's all done at queue generation time now
- reimplement reviewEarly and newEarly by replacing parts of the scheduler,
instead of adding special conditions
- remove references to isDue and priority (1,2,3,4) which is not necessary
anymore
- add option to switch between per-day scheduling and due now scheduling
- newCardsToday() -> newCardsDoneToday()
- don't decrement counts for suspended cards
- make sure to update type when suspending/unsuspending
- fix findCards()
- set hardInterval = 1-1.1 on upgrade, or the default per day scheduling doesn't
make sense
Previously we used getCard() to fetch a card at the time. This required a
number of indices to perform efficiently, and the indices were expensive in
terms of disk space and time required to keep them up to date. Instead we now
gather a bunch of cards at once.
- Drop checkDue()/isDue so writes are not necessary to the DB when checking
for due cards
- Due counts checked on deck load, and only updated once a day or at the end
of a session. This prevents cards from expiring during reviews, leading to
confusing undo behaviour and due counts that go up instead of down as you
review. The default will be to only expire cards once a day, which represents
a change from the way things were done previously.
- Set deck var defaults on deck load/create instead of upgrade, which should
fix upgrade issues
- The scheduling code can now have bits and pieces switched out, which should
make review early / cram etc easier to integrate
- Cards with priority <= 0 now have their type incremented by three, so we can
get access to schedulable cards with a single column.
- rebuildQueue() -> reset()
- refresh() -> refreshSession()
- Views and many of the indices on the cards table are now obsolete and will
be removed in the future. I won't remove them straight away, so as to not
break backward compatibility.
- Use bigger intervals between successive card templates, as the previous
intervals were too small to represent in doubles in some circumstances
Still to do:
- review early
- learn more
- failing mature cards where delay1 > delay0
If the user is not careful to only sync when one side has been modified, they
can end up with cards on one side and not the other. If they then delete a
card, deleting the dangling facts also deletes the fact associated with the
not-yet-synced card. In order to avoid this, we avoid deleting dangling facts
until a DB check.
Attaching new to old causes old to be implicitly commited.
We also can't access old from new if a write lock has been
taken out, so the only option left is to move all the data
through Python and take the speed hit.
Since SM2's grading has a bias towards starting high and going down (fail/hard
decrease the interval more than easy increases it), more conservative users
find their average interval reaches the minimum allowable interval and the
times given by hard/good start to converge. In the future, the whole concept
of using the average interval for new cards should be revisited to see if the
data supports it
suspicious of the previous change, I had a look at the example pascal and
found the EF _was_ actually updated on a failure. The spec is misleading there.
- don't touch factor on fail, as per SM2 specs
- hard code no-punish-on-hard 'learning period' to 7 days so users who tweak
the initial intervals aren't punished too early
