The First Field is Empty Problem

People are constantly asking for “empty first field” for various reasons receiving different niche answers, but again and again question appears anew, so why not implement?

So, my story. I learn languages, so I have a few note types filled with different functions that depend on information I provided or it’s absence. The problem currently is only with my chinese deck. The first field is Sentence (because the main information is the audio-sentence pairs), because I don’t learn words, most words fields throughout the deck are empty. But sometimes I add more information, like words, so some fields/sibling cards appear. And today I decided to create some cards with transliterated names, and again, to avoid Sentence-related siblings, I left it empty. Because it doesn’t allow saving this way, I: input some letter here, save, then open the card, remove it, save (without the error), and when I finish the import session, I go to check —> empty cards (sentence cards that shouldn’t appear in the first place) → remove empty. Too much to do, is it not? I got tired through a first bunch and finally came here.

So, you may say that I’d be better making other note type. But firstly, it will be extra difficult to make identical changes if needed. Through the years I was constantly modificating and unifying all my decks visuals and functions (although a little bit different for different subjects), and it will be boring to do exact steps for much more different types. Secondly, sometimes I add information when it is hard to remember, not to make more instances of the same information I just fill a certain field and the additional sibling cards appear automatically. Thirdly, I also use AnkiDroid and sometimes import from phone too, so the workarounds of addons like ID field or batch edit of the first field will solve only a half of the problem, being an unnecessary extra step. Yeah, it is possible to make this sticky useless field (to spawn later on a megaton of duplicates) to avoid this inconvenience, but is this really a solution? It is almost convenient already, but this single artificial softlock message just prolongs time I spend on card creation, which is already a slow and laborious process in itself. Cards already have unique ID-s (although not for users to use), there is already a function to search through duplicates (which really helps with shared decks’ import in more than one field), so why should we have this status quo of not having duplicates or empty first fields too? Anki is flexible enough to go far beyond basic reverse cards, I can’t see why the first field must be special. People were asking for it for quite a while with different depth of knowledge and for different purposes. So again, why not implement? Also, imagine having less posts on this topic :slightly_smiling_face:

1 Like

Might be related to the fact that the first field is used as the sort field in the browser. If it’s empty, how will ankis card browser sort the cards accordingly? Maybe changing this behavior is possible but it might be a lot of work or cause problems regarding performance.

Well, I imply that it is already working, already here for some reason. Currently I have 432 cards without the first field in that note type and nothing is broken. Also, the filtering stuff you mentioned, it has no problems even there:


(First 4 fields are empty)

Having or editing the field to empty is absolutely okay according to Anki. It is not okay only in the process of creating. I would even thought that it’s just a bug, but then saw all those posts through years with no changes made. Really strange.

1 Like

Where the rubber meets the road for your example might be exporting/importing. I think what you’ve got there would be impossible to export/import as text/CSV – and not without challenges as APKG. Hopefully you’re not considering sharing these decks, but even in your own collection you’ll want to be careful so as to not lose data.

There are obvious advantages to a complex note type that covers all of your possible uses, but you might want to consider adding a keyword in that first field to avoid any disadvantages sneaking up on you!

1 Like

Well, that’s another layer of weirdness. Why are there no warnings when changing the notetype (e.g. putting the later field, which might be empty, to the first place) and then in case of manual deletion, maybe an additional check, but for this problem only? But I guess it will be not the most optimal way to handle the problem. Yes, I don’t plan to export anything and can imagine the difficulties with the text format, but why should there be any with APKG? I believe notes and cards already have their own IDs, so why should they depend heavily on the first field instead? Because now it is funny that it is necessary for advanced cards to have gibberish, anything useless at the top of the card edit window (and not accidentally duplicated!) in each card of a such note type. Yes, unfortunately we also don’t have support for hidden ID fields like all those addons try to do. This is the first major problem I’ve encountered in maybe 4 years of using Anki that doesn’t have any quick workarounds, so I’m asking you: Is it possible that something could be changed in the future?

I think this is because the card, note, revlog and note type ID doubles as the creation date. It is in fact the current time in milliseconds when the db inserted the object: Database Structure · ankidroid/Anki-Android Wiki · GitHub

CREATE TABLE notes (
    id              integer primary key,
      -- epoch milliseconds of when the note was created

And so, if I understand correctly (correct me if I’m wrong here @dae), to ensure no ID collision happens a new ID must be created when importing anything from .apkg. Because, while unlikely, there is a chance that your current db has an object you created at the exact same millisecond as an object coming in as an import.

1 Like

Yes for text, .apkg is totally fine though.

No, the id is the created at time and acts as the id in the card browser. When importing, there’s been a guid for a long time already that is the globally unique identifier.

Actually read the code

I ended up doing some reading on the importer code and found that when importing .apkg files it’s the guid that is used to match notes to each other. The original id is imported to the database and only changed if the id isn’t unique. Because it’s still used when referring to notes in the browser, it needs to be unique. But it’s not the note’s unique identifier in .apkg imports, the guid is.

Importing text files with no ids

The problem is indeed non-apkg importing. You have to have some method of identifying notes that are supposed to be updated by the import. Since there’s no ids in the text file some other content needs to be used as a replacement “id” and using the first field seems to have been decided to be that replacement.

So, basically the first field in a note acts as a surrogate id for importing purposes and thus needs to conform to restrictions on what an id is supposed to be: unique.

If importing non-apkg files could only be used to add notes, not update them, then this first field restriction wouldn’t be needed.

Actually tried importing empty first field notes with text vs .apkg

.apkg

Importing as .apkg works fine, you can get new notes or update existing notes even, if the first field is empty because the guid is what matters then.

Text

Currently it seems to be impossible to import any notes with empty first fields due this being explicitly not allowed in the text importer:

I don’t think I fully understand why this is done. Naturally, every single empty first field note would be found to be a duplicate and could not be matched uniquely to any existing empty first field. But it ought to still be possible to add it as a new note, if that was specified in the import options?

How to allow empty first field

After reading the code more, I’m also thinking if it wouldn’t be ok to not be so obnoxious about this? It really is only a problem in text file imports. Sorting is fine, all the empty first fields just get put together first or last when sorting by that field.

I guess it’s not entirely simple as the text import code needs to handle empty first fields as a special case. The import UI would then need a new option to specifically say how you want to handle those with the options being basically “Do nothing” or “Import as new note” as there’s nothing else that could be done.

2 Likes

There should be few if any remaining technical reasons preventing blank first fields, but it’s still recommended that you pick something unique and always present for the first field, as it’s not very useful to be notified of duplicates as you’re typing the last field in.