budibase icon indicating copy to clipboard operation
budibase copied to clipboard

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.

Open ConorWebb96 opened this issue 1 year ago • 5 comments

Checklist

  • [X] 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

Screenshot 2024-05-31 at 10 37 59

Screenshot 2024-05-31 at 10 38 16

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")
);

ConorWebb96 avatar May 31 '24 09:05 ConorWebb96

This issue seems to still exist, a user has just brought it up in a discussion here: https://github.com/Budibase/budibase/discussions/14632

mikesealey avatar Sep 24 '24 09:09 mikesealey

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.

aptkingston avatar Sep 24 '24 09:09 aptkingston

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.

mikesealey avatar Sep 24 '24 09:09 mikesealey

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.

aptkingston avatar Sep 24 '24 09:09 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).

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.

otichy avatar Nov 15 '24 10:11 otichy

@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!

aptkingston avatar Nov 15 '24 10:11 aptkingston

This issue has been automatically marked as stale as there has been no activity for 6 months.

github-actions[bot] avatar May 14 '25 11:05 github-actions[bot]