Can I store custom metadata in a note type?

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

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
3 Likes

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?

do I understand correctly that the size overhead of an empty field is just one separator byte (0x1f) per note?

I hadn’t even considered how much extra data using a marker field would add to each note, but yeah that seems right according to the db details.

I didn’t realize until now but that seems to be the reason adding/removing/repositioning a field requires a full upload: every note for the note type needs to have those separators added/removed or the order of the values changed.

1 Like

Arbitrary keyed values can be stored in a notetype, and doing so is going to be more efficient than adding an unused field. Just please avoid storing large amounts of data, as that will slow Anki down.

notetype_dict["foo"] = "bar"
4 Likes

Oh, nice. Are those included in an exported .apkg?

2 Likes

Oh, awesome! I haven’t released the update yet, so can still change to this easily. Will try it out and mark it as a solution if everything works. Thank you!

Seems to be included. I’ve exported my collection, then removed all my note types, then imported it back. The restored note type shows up in my addon, filtered by a custom key.

4 Likes