My MongoDB query returns field names like this
"RecordNo"
"wtfactor"
"PrjName"
"LtCallDt"
"CallDurM"
But the new Table component renames them like this:
"Record no"
"Wtfactor"
"Pri name"
"Lt call dt"
"Call dur m"
Is there any way to turn this off and display the column names exactly like the actual data?
Hi @MatthewFass,
It looks like you can go into each column and edit the label to be the same as your db, but I don't see a way to do this by default across all columns 
I'll request this feature internally
Thank you for looking into it, Tess. The problem is I can't work with the new table component if this questionable "feature" can't be disabled because it messes up our CSV import and export workflow. For now I will stick with the legacy table.
Similarly, the default {{ _.startCase(item) }} in the Mapped value is a bit presumptive and, speaking for myself, almost always gets deleted!
Hi @Schteevynn, just wanted to double check, do you mean for the automated column header? or the table values?
The latter, I'm referring to a column's mapped value.
Matthew's point is similar – the Label field seems to be automatically populated with a reformatted version of the Source field (in the screenshot, I did not remove those underscores nor change case). I pretty much always customize the label anyway, so it's not much of a change for me. But if you prefer the label to match the source, like Matthew does, you'd have to manually revert each label.
The Mapped value field now includes the {{_.startCase(item)}} by default for some column types, so you have to go and delete for those columns if you want the column to display the data "as is" from the data set.
Quite a few "whoa, why does that look so weird" moments before drilling down and removing the startCase reformatting.
Got it! Thanks for the screenshot. I see a request on file to fix this issue -- I'll add your +1
+1 for this, it's really unpleasant to infer formatting on the user's behalf when working with proper data.
+1
I know this is an old thread, but...
+1
Automatically transforming the data that goes into the table by applying _.startCase to column labels or row data, and automatically choosing a column content format makes this component unusable for my team, which is unfortunate there are a lot of nice features to it that are not available with the Legacy table (like row grouping).
Adding another bump on this thread... @retool I just know you're going to want to deprecate the legacy table at some point and that is going to wipe out our app unless you fix this issue.
Hi everyone,
Thanks for the additional feedback! I have bumped this internally. I'm not sure what the outcome will be yet, but I'll follow up on this thread when I get an update.
For some background, the new table was designed to help build apps quickly by "just working" out of the box, with the option to customize if needed. While these automations can be removed from your table, I can certainly appreciate that it defeats the intention of speed of development if you're going in manually to remove the auto-formatting.
Looking towards a solution, is the main feedback that it is tedious to have to remove auto-formatting & manually change column types for each table?
That's correct. Tedious is one word for it. Unintended data transformation is the real problem.
For example, in my app I'm sometimes pulling in 30+ columns/fields from a MongoDB and off the exact fields I'm pulling change depending on the query. The user can edit in the table and then upload the changes back to the DB.
In the legacy table, this was no problem but with the new table as is, the auto-formatting essentially changes the data structure in my DB, which is obviously not desirable.
A simple auto-format on/off toggle on the new table component would solve the problem.
Thanks for bumping up.
Now that legacy tables are officially deprecated, is there an update on turning off auto-formatting in the new tables component?
No update yet, unfortunately, but it is something we plan to support in the future