Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Same fields, different note ID lead to problems in Anki. Should GUID take note or deck ID into account? #61

Open
tbm opened this issue Dec 2, 2020 · 2 comments
Assignees

Comments

@tbm
Copy link

tbm commented Dec 2, 2020

I created two decks with genanki:

  • Deck A has its own deck ID, is own note type with its own ID. Let’s say fields A and B. I create one note with some values.
  • Deck B is identical but has its down deck ID and note type ID. But same fields and test note with same value as test note for deck A.

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:

I think the original intention was to combine notetype ID + guid to get a standard UUID size, but I don't think the current code is
doing that. I'd be surprised if conflicts were common in practice however, outside of usage of third-party tools that are not
generating them randomly.

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).

@kerrickstaley
Copy link
Owner

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).

@kerrickstaley kerrickstaley self-assigned this Jan 16, 2021
@kerrickstaley
Copy link
Owner

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants