Sort broken for single select fields in large tables

I’ve finally caught a really annoying sort issue on video.
When sort and filters are applied, in combination with column order change (and lots of hidden columns) - sort is impacted by changing a value of unrelated field.

here - we sort by a “company” column, but changing the “helper” column impacts sort.
the helper column is not part of filters or sort applied.

Strangely, it only happens for a few cells at the top of the table.
I am not able to reproduce it for small test tables, so it may be a deeper issue.
it is stable, though, so it does not go away after page refresh, etc.

I will be able to take a closer look at this some time next week. In the meantime - what info would you need to identify the underlying issue?

quick follow up:

  • turns out it looks as if for large tables some rows get sorted incorrectly at first try when combined with filters narrowing down the selection significantly (compared to the size of the table). and issue seems to affect items with high ID number (perhaps if moved to the top by sort)

  • here the company names are blurred, but the affected rows (top of the table) are sorted incorrectly. After these are sorted incorrectly in that way, every attempt at changing other values in the row results in sort reshuffling. After I click other cells in the affected rows enough times, they finally reach the intended correct sort and then they stop moving.

Seems like this only happens when sort is applied to single/multi select fields.
Sorting by number columns or name for the same set of data does not cause this issue.

Hi @dev-rd,

in order to help you could you try to work out a reproducible example with steps to reproduce?

@petrs I am now able to consistently reproduce this issue with sample test data.

I can send you the CSV in a PM.

steps to reproduce:

  1. create sample data for 10 000 rows.
  2. fill a few columns with random and ordered data
  3. for the target “target” single select column - distribute a sample of the ‘select option’ items randomly throughout the table
  4. then add patches of contiguous items of the same kind (like “aaaaa” in the example in the video) in different parts of the table - also near the bottom).
  5. upload data to Baserow
  6. convert the ‘target’ column to single select
  7. sort (Z-A)

Not sure about the threshold of items or rows for this to occur, but for 3000 rows I was not able to get this after a quick try.
Also - in some tables we observed this only when filters were involved.

I do hope this is enough for you to investigate the issue, as this actually seriously impacts the work we do in Baserow.
and I think this will affect anyone dealing with larger tables sooner rather than later…

Thanks!

Hey @dev-rd, the problem was related to the backend and frontend using a different sort collate, causing the frontend to think that the position of the row should be different. It is resolved for the single select, multiple select, and multiple collaborators field type in this merge request Resolve "Collate single select, multiple select, multicollaborators fields for sorting" (!2811) · Merge requests · Baserow / baserow · GitLab.

It’s currently blocked because we need to wait for the response of one of another developer in the team on something else that could prevent this from being merged.

I’m confident it will be fixed in the upcoming release, though.

1 Like

@bram thanks so much for this!!!