- base the 2.0 model id on the 1.2 one so we don't get new models each time we
reimport the file
- when determining if we can reuse an existing note, it must have the same
model id, and the model must have the same schema
- make sure we check templates when determining schema
- if schema has diverged, note needs new guid
when a card has a low interval like 1, you can end up with next times of
2,2,3, which some users think is a bug. change the code to yield 2,3,4
instead.
- cram decks no longer pull cards from other cram decks, as tests like is:due
don't make sense on crammed decks
- cram decks now default to not overriding the original deck's steps
- remove obsolote dyn_failed sort order - have to fix this in upgrade
- search/limit/order properties have been merged into a list, in case we may
want to support multiple queries in the future (eg 10 cards from tag A, 20
cards from tag B)
- added a resched option to disable boosting/failure - not yet implemented
- added an unused flag to allow cards to persist in the cram deck after
graduation. implementing this will take some work and won't come in 2.0
- instead of is:filtereddeck, use deck:filtered
- new per-character tokenizer that is easier to read and maintain
- OR searches now supported
- grouping with ( and ) now supported
- sorting is off by default now
- searching in html is disabled for now, but may come back later
- use ? arguments instead of named arguments to ease porting to other
platforms
- field:foo is no longer wrapped in implicit wildcards
- avoid joining notes table if it not required - about 30% faster
- fixed sql injection bug in findNids()
- commands no longer have to take care of negation themselves
- commands can return nothing to immediately flag the query as invalid
The way we were handling 1 day+ learning intervals was not great - they'd show
up at the start of a new day before normal reviews, meaning the hardest cards
came first. In previous Anki versions we deliberately sorted the queue in the
opposite order to prevent that. When relearning the cards the next day, if you
failed a card and expected to see it in 10 minutes that wouldn't happen
either, as all the overdue cards took precedence.
To fix this, we put cards that are due tomorrow or later into a separate queue
(queue 3), and pull cards from that queue only after the reviews are done. In
the future it might also be nice to move overdue learning cards into that
queue automatically at the start of a session.
When a user has learning steps that extend past the daily cutoff, we end up
counting them all instead of only the ones that would be done today. In order
to avoid this without expensive calculations or db schema changes, we
calculate the number of steps until the daily cutoff and pack it into the left
column, as totalLeft + leftToday*1000.
