I was able to do it previously but failed with the recently updated Version 2.1.55 on Linux.
Say there are Fields A, B and C on the note. Field A is the index ‘a’ (to eliminate other factors, it’s set to both the sorting and the first column). Field B has content ‘b’ while Field C is empty. Create a text file with ‘a\tc’. Import the text file. Two fields are identified. Let’s allocate ‘a’ to Field A, and ‘c’ to Field C.
What I expect is an updated note with Field A = ‘a’, Field B= ‘b’, and Field C = ‘c’. But the result is instead Field A = ‘a’, Field B empty, and Field C = ‘c’.
I’m not quite sure about that, but I think Anki decides that two notes are duplicates if their sort fields are the same. If you want to update a note based on the field A, you should just need to make it the sort field.
This is not possible, as there would be no way to distinguish between a deliberately empty field, and one where you wanted to preserve the existing field. If you export a csv file, make the changes you want, and then import it again, it will ensure any unmodified fields are preserved.
It’s a very important feature to me since I have tens of thousands of notes and more than one hundred fields. Say if I want to update 100 notes where the index fields are obtained from a separate vocabulary list, simply to select these 100 notes in Anki or match them to a whole deck of cards in Python are both troublesome, especially if I need to perform this regularly.
In previous versions, to deliberately leave a field untouched, I simply set the corresponding field to nothing when importing. If I wanted to deliberately update a field to empty, I would map it to a column which is set to empty in the csv file.
Sorry, I misspoke. The presence/absence of the field in the mapping should be sufficient to distinguish the two cases, and you are right that this used to work.
Please note that 2.1.55 has not even received a beta release yet.
@Rumo the old code handled this by starting from the existing note text in processFields(), so unmapped fields remained unchanged. It looks like we have access to the existing note in update_with_note() - could we take a similar approach there?