Table using an external database with a formula column as the primaryDisplay show it on the far right instead of respecting the order of the dataview.

[ConorWebb96]

Checklist

• I have searched budibase discussions and github issues to check if my issue already exists

Hosting

• Self
  • Method: docker compose
  • Budibase Version: 2.27.5
  • App Version: 2.27.5

Describe the bug
This issue only appears if the table component is linked to a dataprovider as its source. If you directly reference the table the order will be correctly reflected.

To Reproduce
Steps to reproduce the behavior:

1. Import app attached below.
2. Use the table create script attached below to create the database.
3. Fetch the tables in Budibase
4. Add a formula column, doesn't matter what its called.
5. Set the formula column to be the primaryDisplay column.
6. Create a new screen that has a dataprovider linked to the newly created table.
7. Add a table component nested inside the data provider, make sure the table is using the data provider as the source of its info.
8. See the error, if the formula is the primary display it will go to the far right of the screen instead of being the first column.

Expected behavior
primaryDisplay should always be the first column shown in the table.

Screenshots

App Export
formula-column-primary-display.enc.tar.gz

CREATE TABLE "public"."users" (
    "id" varchar(10) NOT NULL DEFAULT ('us-'::text || lpad((nextval('user_id_seq'::regclass))::text, 5, '0'::text)),
    "name" varchar(100),
    "created_at" timestamp DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY ("id")
);

[linear]

BUDI-8313 table using an external database with a formula column as the primaryDisplay show it on the far right instead of respecting the order of the dataview.

[mikesealey]

This issue seems to still exist, a user has just brought it up in a discussion here: #14632

[aptkingston]

The issue here is that you shouldn't use a data provider with the table - you should use the datasource directly. If you use the datasource directly then the display column will be in the correct place. I think I might actually prevent using data providers in tables altogether as it causes more issues than anything.

[mikesealey]

Would that work then include making Dynamic Filters work on tables? There are also a handful of bindings available from Data Providers that are not found in tables that are useful, like rows, and rows-length.

[aptkingston]

Dynamic filters wouldn't work with tables no, but tables do have their own in-line filtering implementation (but it's more basic than the dynamic filter).

In terms of bindings, if there are use cases for getting the number of rows currently loaded in a table then it would be very easy to add that if we want to. I don't want to expose more bindings for rows though, because it can be huge and would have a big performance penalty since tables load rows automatically when scrolling.

By using a data provider rather than the datasource directly you miss out on loads of features, including pagination, editing, adding rows, deleting rows, the soon to be released row actions etc. I would heavily discourage it. If we need more features added to tables so solve certain use cases then we can open feature requests for those and see what we can do.

[otichy]

Dynamic filters wouldn't work with tables no, but tables do have their own in-line filtering implementation (but it's more basic than the dynamic filter).

This doc https://docs.budibase.com/docs/adding-a-search-field specifically directs you to use the data provider to get the dynamic filter and dynamic filter is really useful for a table. Not only does it allow you to be more precise with the condition, it allows combining multiple conditions and also filter aggregated columns with multiple values (from relationships) that are otherwise unfilterable.

[aptkingston]

@otichy I've got a PR up to address this issue (which also will fix your issue), so you should be able to continue using the data provider as the source for your table. Hope that helps!