With Anki 2.1.35*, exporting a newly-created deck does not cause the generated uuids (for deck, deck config and models) to be saved. This means that if you export the same deck multiple times, the uuids will be different each time.
* and probably all other versions after 2.1.26 — I haven't explicitly checked, but f637ac957d206ead619d54d6cf86eb8958ea508c and f592672fa952260655881a75a2e3c921b2e23857 which, based on a cursory git-blame introduced the changes in Anki, were both between 2.1.26 and 2.1.28
It's because decks.save() and models.save() now have no effect without an argument, rather than (as previously) saving all decks and deck configs or models (respectively). Also, the .flush() methods are now legacy no-ops.
This is analogous to the import crash post 2.1.26, (which was partially caused by decks.save() no longer saving all decks) except that in the case of exporting, unlike importing, not saving the deck does invalidate the entire operation (so there's not crash), just prevents CrowdAnki's changes from being applied.
Steps to reproduce
Create a fresh Anki profile.
Create a new deck and add a note to it.
Export the deck with CrowdAnki. (Snapshotting works as well, and conveniently provides a git diff and log for 6, so I advise using it, where possible (testing the export of subdecks is a case where it's not possible, since snapshots deal with subdecks slightly differently than a direct export of the "parent" deck does.)
Restart Anki.
Export the deck again.
Compare the deck.json from 3 with that from 5, e.g. with git log and git diff, if snapshotting was used.
Expected results
The two deck.jsons are identical. (git log lists only one commit.)
Actual result
The two deck.jsons differ — the crowdanki_uuid for the deck, the deck config (deck_config_uuid) and the models (note_model_uuid) are all different. Note that if you omit restarting Anki (4), then only the deck and deck config uuids are different — the note_model_uuid somehow (I haven't investigated) persists until restart.
Discussion
Repeating 4-6 will repeatedly change all the uuids, ad infinitum or until you re-import the exported deck (at which point the uuids will be entered into the database).
With Anki 2.1.35*, exporting a newly-created deck does not cause the generated uuids (for deck, deck config and models) to be saved. This means that if you export the same deck multiple times, the uuids will be different each time.
* and probably all other versions after 2.1.26 — I haven't explicitly checked, but
f637ac957d206ead619d54d6cf86eb8958ea508c
andf592672fa952260655881a75a2e3c921b2e23857
which, based on a cursory git-blame introduced the changes in Anki, were both between 2.1.26 and 2.1.28It's because
decks.save()
andmodels.save()
now have no effect without an argument, rather than (as previously) saving all decks and deck configs or models (respectively). Also, the.flush()
methods are now legacy no-ops.This is analogous to the import crash post 2.1.26, (which was partially caused by
decks.save()
no longer saving all decks) except that in the case of exporting, unlike importing, not saving the deck does invalidate the entire operation (so there's not crash), just preventsCrowdAnki
's changes from being applied.Steps to reproduce
deck.json
from 3 with that from 5, e.g. withgit log
andgit diff
, if snapshotting was used.Expected results
The two
deck.json
s are identical. (git log
lists only one commit.)Actual result
The two
deck.json
s differ — thecrowdanki_uuid
for the deck, the deck config (deck_config_uuid
) and the models (note_model_uuid
) are all different. Note that if you omit restarting Anki (4), then only the deck and deck config uuids are different — thenote_model_uuid
somehow (I haven't investigated) persists until restart.Discussion
Repeating 4-6 will repeatedly change all the
uuid
s,ad infinitum
or until you re-import the exported deck (at which point the uuids will be entered into the database).