Columns types changing on their own

A few times I’ve noticed that I might enter or copy data into a cell and something about that data causes the field type to automatically change.

An example: I have a text column. I type a date in that column. It changes to a date column. (I can kind of see why this might happen, but I definitely don’t want it to happen and can see no way of stopping it.)

Another example: I pasted some zip codes into a number column. That field converted to a single-select dropdown. Same thing has happened with text. (No clue why this would happen, and doesn’t happen consistently.)

The first couple of times this happened, I thought it was a fluke, but now it’s happened enough times, I think it’s a bug…

3 Likes

Dear @Kelly_Claus,

Based on the content put in a column, Coda creates automatically a column type, without asking for your consent.
It’s not a bug, but I agree that you will not always benefit from it.

To my opinion, this should be set optional or at least the “Maker” :building_construction: to confirm.

2 Likes

Hi @Kelly_Claus ,
as a matter of fact it’s a feature rather than a bug.

It’s called (data) type inference and it’s a way to simplify the life for most of the times.
Excel and Google Sheet - as well as other data related tools - do the same.

I understand that from time to time it can be annoying, but let’s say it usually happens quite rarely compared to the benefits.

In case this is something really affecting your work, then maybe it worth understanding better what kind of operations you usually do and how to overcome with that.

1 Like

@Federico_Stefanato and @Jean_Pierre_Traets thanks for responding.

I assumed this was the case when it happened with dates, but it doesn’t make sense why a column would ever change to a single-select dropdown, does it?

Hi @Kelly_Claus,
I don’t know exactly the threshold adopted to consider a set of values as coming form a select list.

Let’s say that post codes are good candidates: always 5 digits and perhaps some repeated values it would guess that these are - well - codes :slight_smile:

I’ve been facing this issue multiple times, and my workaround is to create a “hidden row” (create one checkbox column named “_hidden” then filter all data by this column value, and put a data on the column you want to keep). I hope example explains:
image

But yes, my suggestion to Coda is not to change column type if it has been chosen explicitly by user.

Hi, is there any news on how to workarround this? My case is users auto changing column type when type date type titles in a row. If it’s a feature it should be optional to disable it. It’s affecting several times a week our workflow

1 Like

Dear @Digital_99

I could not find the relevant post, but somebody suggested to paste from the second row the content in the table and then to delete the empty row.

This has been so far a work around for the time being.

As we see from recent posts, the Codans start to catch up with pending points that we experience as “improvements of life” - lets hope that this subject soon sees daylight too.

1 Like

I’m using it as a form, so that workarround doesn’t help for us. Let’s hope Codans catch up to this soon enough

1 Like

I would like to report that I have the exact same bug.

A text field is automatically changed to date or number based on the content.

Since the users use the doc exclusively on the phone, they always need to report it to me and wait to fix it (change it back to text field). Until then they are blocked from using the table

2 Likes

And I would like te report that I have a button column that seems to have changed itself into an empty text column. When I noticed (one hour ago) I went to version control to look up an old version of this button. I can see it grayed out in version control preview, but when I copy that version to a real doc, the button disappears in front of my eyes.

This happend to be a simple function button, but for some of my buttons I really can’t afford for this to happen, in particular if I can’t trust version control.

5 Likes

If you have ever used CoPilot (an AI pair programmer that predicts the code required based on your comments), it performs similar inferencing assumptions and it is vastly correct in making these assumptions. It’s certainly not perfect, but it is learning.

I’m delighted to see that the Codans have begun to lean on AI to advance the science of Maker tasks. I hope the underlying AI mechanisms are learning when we correct missteps like these.

Along this path to faster and more efficient Maker assistance there will be bumps and mistakes, but inferencing based on previous patterns and known best practices is likely to stick now and eventually transform how we make Coda applications. Imagine building a table and being largely unfamiliar with advanced features that could improve your user experiences. This type of assertive Maker assistance may become extremely valuable and especially as the techniques and more advanced features continue to emerge. The future of app development cannot end with no/low-code; it must embrace the capacity to help Makers plan, design, and architect solutions to meet increasingly complex requirements.

Curious @Federico_Stefanato is Coda actively developing underlying AI based on GPT-3?

If this is indeed related to an attempt to exhibit helpfulness, it suggests the AI is not learning. :wink:

sigh…

trouble with AI = very big A & very small i

1 Like

I have this issue as well with a Date type column turning into a Select List and a Text tyoe turning into a Number. This is happening on a front facing data entry table with 20 users and its getting frustrating to get an email that someone is unable to enter their data until I log in and change the types back.

I get the inference thing, but it would be nice if there was the option to turn that off for what I decide are critical columns.

2 Likes

Agree that this is annoying when it is not wanted—and it has unfortunately been disrupting people ever since!

Trigger:

There is no other row in the table with a non-blank value in this field. In other words, this conversion will happen if the table is empty, or if every other row in the table has no value for this column.

Current workaround:

Have a row somewhere with a non-blank value for this column, and filter it out of view.

How to influence change:

Vote on the Text Column Type that stays text Suggestion Box entry.

Related:

3 Likes

Hi,
I consider this behaviour unpleasant, and agree with the idea ther should be an option to deactivate it .

I am building a kind of shopping cart for some lambda users, and dont wish them to come across error messages, red flags in cells corners and other disturbing stuff.

My “Shopping” page has on left side an items list to choose (view of an invetory table), and on right side the cart. Ther is buttons and actions to copy the chosen left items and populate the cart with them.
Works fine sofar, and I decided to set a condition for the item to be copied in the cart : user need to input a quantity for the item. But I want the user to be able to choose between number or text, such as “25” or “two fullspoons” etc…

So I also had the idea of the dummy row in the inventory table, and it works fine, but is tricky when it comes to maintenance : one more workaround to keep in mind…

I am using CODA since two weeks now, and as a kind of skilled SpreadSheets and MySQL DB developper, I am thrilled by the intelligence of CODA’s architecture, but disappointed when it comes to “hesitate” between spreadsheet or database kind of behaviours… So powerful and versatile environment makes very annoying this kind of lack of options…

Hope there will be an option soon…

1 Like

This keeps happening to me. I don’t understand the idea of keeping a row with a value and filtering it out as some have suggested. I have hundreds of rows that are text type but if the user puts 1 date in, everything switches. I understand interpreting types but this is a BUG and user hostile.

3 Likes