Can I store custom metadata in a note type?

Anki Development
1

Hello! I’m developing Sonaveeb Integration addon which allows you to generate Anki notes for Estonian words. The addon creates its own dedicated note type. It can also update it automatically if the upstream version changes.

Currently I’m working on allowing the user to create their own note types with custom card templates. I can distinguish if the note type is valid for the addon by checking if it has all the necessary fields. But I also want to support updating fields for the user note types, when outdated. So I also need to distinguish if the note type is intended for the addon, which it might be even if not valid.

For now I require the intended note type names to start with a predefined prefix (“Sõnaveeb”), but it’s not intuitive, and may also let false positives in (the user might want to have a note type named “Sõnaveeb Something” that is not related to my addon). Ideally I would want to plant some custom flag in the default addon’s note type when I create it programmatically, so that when user clones it the flag would be inherited. Is something like this possible? Alternatively, is it possible to check whether one note type was originally cloned from another, even after they were modified?

2 Likes
2

There isn’t anything suitable in the available database fields, I think: Database Structure · ankidroid/Anki-Android Wiki · GitHub

A hack will have to suffice. My suggestion would be to add one extra field named something like __metadata_dont_delete_Sõnaveeb_v1.0.5.

  • Make the field name as long as you want and include whatever info you need.
  • Being a field, it’ll be included as-is when cloning the note type
  • You can make your addon update the field name as needed
  • Just changing a field name doesn’t require a full collection upload, unlike adding or removing a field would
  • It isn’t perfect as a user might still delete it despite warnings included in the name but it ought to do the job
2 Likes
3

Thanks a lot for the answer! I considered adding a “marker” field, but now I have a lot more confidence knowing this is a recommended solution. Looking at the database structure, do I understand correctly that the size overhead of an empty field is just one separator byte (0x1f) per note?