Bug: Select fields not importing correctly from Airtable

I just got Baserow running locally through docker to experiment with, and I’ve run into a bug multiple times already where an entire column in a table suddenly gets cleared, as in, the column still exists but the data in the column is deleted from every single row, irreversibly.

So far this has only occurred with “Single select” field type columns, but I’m not sure if that’s just coincidence or not.

It happens occasionally when doing certain actions related to the column, such as renaming it, editing the field type, or creating a lookup field to it in another table.

I would love to be able to switch from Airtable to Baserow, but random data deletion is a pretty hard catch.

Some additional info about my setup: I’m using Google Chrome on Linux, and running Baserow 1.12.1 using docker compose. No errors show up in docker logs when the bug occurs.

Hi @Jamac , thanks for the bug report. Some quick questions to start with to help us reproduce this issue:

Is it the literally “Single Select” field itself that is being blanked?
Or the lookup field of the single select that becomes blank? Currently if you rename the “target” of a lookup field there is a known bug that will put the Lookup field into an error state:
image
No data has actually been deleted here, it’s just because the lookup field was looking up a specific field name and so after renaming that field you’ll have to re-select the target field in the lookup to fix it and show the data again.

If this isn’t the issue do you have a few example screenshots of the tables in which this is happening + a series of exact steps that I can follow to reproduce? I’ve tried a wide range of renaming/editing etc as you’ve suggested and the only time I can cause a blank column is the previous lookup field going blank bug due to a rename.

Here is the bug report/issue tracking the renaming bug: Renaming the target of a lookup field puts it into the error state (#1049) · Issues · Bram Wiepjes / baserow · GitLab

1 Like

To clarify, it’s the column being looked up that gets cleared, not the lookup column.

But, after some more experimenting, I think this issue is just a symptom of another issue. I probably should have mentioned in the original post, but I’m importing data from Airtable. It seems like the select fields don’t always get imported correctly, and that’s what’s causing them to get deleted sometimes.

On certain select fields (both single and multi) in my imported database, the data in them looks like it’s there, but it’s not actually, which is why it gets cleared after creating a lookup. Here’s an example of what I mean:

I renamed the option “Live” to “Live TEST” and clicked save. The data in the column didn’t update, it still says “Live”. This persists through page reloads and even restarting the Baserow container. If I highlight, copy, and then paste some data from that column back into itself, it pastes empty cells.

The data I’m testing with here is actually some client data that we manage with Airtable currently (but would love to migrate to Baserow). I haven’t been able to reproduce this with any other data, and, while this data isn’t confidential, it’s also not really something we would normally share, so I’m going to go see if it’s alright to just PM you a link to the base where this is happening. Either way, hope this info helps.

Ok, it’s fine for me to just share the link to the base: Airtable - Engineering
I’m also renaming this thread to reflect the actual issue.

Thanks a ton for providing the share link, i’ve been able to track down the problem. Its very specifically a bug in the Airtable → Baserow importer that is not setting up these select options correctly in Baserow.

I’ll explain exactly what the bug is as perhaps this might help you work around this import problem for now.

  1. Both your Model and Floorplan tables have this “Status” single select field
  2. When importing these columns we create the corresponding “Baserow Single Select” field
  3. During this creation, we assume that the “internal id” that Airtable uses per single select option is unique per column. So we were expecting that the “Live” select option in the Model table will have a different id than the one in the Floorplan table.
  4. However it looks like this was an incorrect assumption, Airtable is returning the same ID’s for select options in both the Model and Floorplan tables.
  5. This then causes the select option fields to be created in Baserow by the Airtable importer with invalid data and cause the bugs you are seeing.

My idea for a temporary work around until we fix this bug is: In Airtable if you converted one of the “Status” single select fields to a text field and then back to being a single select this would force Airtable stop using the same internal id’s as the other “Status” field. Then a re-import of the Base into Baserow would then hopefully produce a non-buggy single select table.

Finally, it looks like this bug will appear whenever a single select field has been duplicated in Airtable. However i’m not sure how this happened with two fields in two different tables like in your Base. I’ve made this Baserow issue tracking the bug fix and will keep you informed on it’s progress :slight_smile:

1 Like

The workaround you suggested worked great. Thanks!

1 Like