- 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
Decks now have an "update sequence number". All objects also have a USN, which
is set to the deck USN each time they are modified. When syncing, each side
sends any objects with a USN >= clientUSN. When objects are copied via sync,
they have their USNs bumped to the current serverUSN. After a sync, the USN on
both sides is set to serverUSN + 1.
This solves the failing three way test, ensures we receive all changes
regardless of clock drift, and as the revlog also has a USN now, ensures that
old revlog entries are imported properly too.
Objects retain a separate modification time, which is used for conflict
resolution, deck subscriptions/importing, and info for the user.
Note that if the clock is too far off, it will still cause confusion for
users, as the due counts may be different depending on the time. For this
reason it's probably a good idea to keep a limit on how far the clock can
deviate.
We still keep track of the last sync time, but only so we can determine if the
schema has changed since the last sync.
The media code needs to be updated to use USNs too.
