Open tbm opened 3 years ago
Thanks for the detailed bug report that clearly explains the problem, and for doing the investigative work on the Anki forum!
I think your proposal of incorporating the mid
when computing the GUID is the best way forward. This would be a backwards-incompatible change and we would roll it out in a slow fashion, starting by making it optional and issuing a DeprecationWarning
when people don't use the new GUID method, and then later (maybe 4-6 months later) releasing a new version of the package that uses the new approach by default. We would need to retain the old method for backwards-compatibility with decks that are already released. I will start working on this when I have time.
I don't think it makes sense to incorporate the deck ID, because you often do want deduplication across decks; if the exact same card in a .apkg
I'm importing is already in my library, I usually don't want another copy of it (although then it's confusing because the card is in the old deck so you won't see it if you only study the new deck...not clear what the best UX is here).
@tbm for now, you can either assign the .guid
property on each Note
object, or create a Note
subclass with a custom guid
property (example).
I created two decks with genanki:
Importing deck A works, but importing deck B fails after I import A: "Notes skipped, as they’re already in your collection"
So Anki thinks the notes are identical because they have the same GUID. The
mid
of course is different.I raised this topic on the Anki forum and it seems they don't consider this worth fixing. Anki author Damien Elmes said:
So I'm wondering if genanki should also use the note ID or deck ID to generate the GUID. This would avoid the problem I encountered.
One question is how to handle such a change without breaking existing deks (GUIDs).