Importing cannot partially update existing cards

Syncing & AnkiWeb
1

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

Is there a fast way to achieve the goal?

2

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.

3

It’s actually based on the first field: Detect dups on Sort Field instead of 1st field

1 Like
4

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.

5

It WAS possible in previous versions.

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.

6

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?

7

I don’t think so. The distinction between unmapped and empty fields is already lost at this point. I’ll look into it.

3 Likes