The 'entry due' is the due time of a failed card before it enters the learning
queue. When the card graduates or is removed, it has its old due time
restored. We could pull this from the revlog, but it's cheaper to do it this
way.
We originally were triggering on 100 opcodes, because at the time we were
doing write-heavy alterations to the DB for inactive tags, and a higher level
of opcodes would pause the interface for a long time. The query structure is
different now, so we can afford to save the overhead of more frequent calls.
With the change, a .reset() triggers the handler 3 times; fixIntegrity()
triggers it 30 times over a period of 4.5 seconds.
A lot of the old checks in fixIntegrity() are no longer relevant, and some of
the others may no longer be required. They can be added back in as the need
arises.
We want to ensure that we never recycle ids from deleted cards. We could do
this with an autoincrement column in sqlite, but it's cheaper for us to handle
the ids ourselves, as the deck object is always in memory.
- remove revlog.py and move code into scheduler
- add a routine to log a learn repetition
- rename flags to type and set type=0 for learn mode
- add to unit test
Because the cards table is small now, loading it in and doing a table scan
isn't necessary. The facts table is bigger now, so we still need that index.
When adding facts, you can now pass in a group id which the GUI should support
editing. Templates will have an optional group id which overrides the provided
id, so users can automatically put certain card types in a different group (or
all of them, if desired). Greying out the group box in the GUI in that case
would be a good idea.
This means that the default learn queue sort order doesn't need another column
in the index, but it also means that generated cards will have a higher id,
and would appear later even if they have a lower ordinal. This is probably an
infrequent issue, and a plugin which rewrites ids would probably be an
adequate solution.
Our goal is to allow decks created on one platform to use similar fonts (even
if named differently) when moving to another platform. The old solution wasn't
useful for the web version or mobile versions. Instead, we store a mapping in
the deck, and when generating the CSS, we list all possible fonts. An option
in the interface for the user to add extra fonts might be nice.
