Bug fix: cleaning up sorting options

Hi all,

We’re cleaning up the list of fields you can sort searches and lists on. We had a bug for a long time where we displayed every field in the sort list, including fields that we don’t have a well-defined sort order for (such as lists of numbers, or custom things). We are deploying a change shortly that will hide these fields from the dropdown.

This change won’t affect apps that are already using one of those fields to sort on: the search will still be sorted in the same order that it is sorted on currently. (In practice, if you are sorting on a field that has a custom thing, you have been getting a lexicographic sort on the unique id of that custom thing, and if you’ve been sorting on a list, you’ve been getting a pretty arbitrary sort order). You’ll just no longer see the option in the editor.

The field types we do support are:

  • Numbers (from smallest to biggest)
  • Dates (from earliest to latest)
  • Date intervals (from shortest to longest)
  • Text (lexicographic dictionary sort)
  • File / Image (lexicographic dictionary sort on the url)
  • Yes / No (first no, then yes)

As we define how other fields ought to sort, we’ll add them back to the list. (We’d like to eventually support sorting by sub-fields on custom things, but this is not going to be in the immediate future).

11 Likes

Sounds like a good fix. Thanks for the update.

Is there an easy way for us to know if our apps use one of the outdated sort orders (i.e., without having to go through all of our apps workflows)?

Not super-easy. They’ll show up as warnings in the issue checker eventually, but we don’t refresh the issue checker until you visit the page that it’s on. That said, there’s no real need to proactively hunt them down: if you hadn’t noticed a problem with them already, then it’s probably a situation where the sort order doesn’t matter that much to what you’re doing or the sort order that you’re getting is fine.

Sounds good. Visiting each page sounds dead simple too. Thanks @josh. Keep up the good work!

Hi @Josh,

I understand the reason why you had to do this, but it’s rather inconvenient to not be able to sort by fields that are “things”. There is probably a huge number of situations where this type of feature is needed. Example:

Assume I have two tables ORDER and COMPANY
ORDER has a field called Company, which is of type COMPANY

COMPANY has a field Company Name, which is of type text.

If I want to create a Repeating Group of ORDERs and sort them by Company Name, I just can’t.

I want to preserve the type COMPANY of the Company field in the ORDER table because it makes many other things really easy. The purist in me does not like adding yet another field to the ORDER table (say Company Name Text, of type text) to facilitate the sorting.

Other rapid development tools like Bubble solved this problem by configuring for each table a default sort key. In its simplest form, that key would be one of the fields in the table. In my example, I’d set the COMPANY table to use Company Name as its primary sort key.

If I were to set the “sort by” parameter in a Repeating Group based on ORDER to be the field Company (of type COMPANY), then the sort would be done by COMPANY’s Company Name.

At the time I found that tool’s approach restrictive (why can’t I indicate the sorting field of a referenced table in each sort instead of once when configure the table?) but it is indeed better than not being able to sort at all…

(There was a graffiti in my alma mater here that said “Fish don’t appreciate water until they meet air.” :slight_smile: )

Is there any plan to address this?

Forgot about this topic. I haven’t really gotten a response on this topic Sort repeating group: empty fields on top - #3 by vincent56

so let me explain in a little more detail, perhaps it makes sense. It seems sorting on a number or date doesn’t take empty fields into account.

I sort on ‘order’ which is a number:

Ascending:

Descending:

But there are empty fields that is stuck at the bottom:
image

When I sort on Name (a text field),the list gets sorted as I expected, with empty ones being sorted as well.:

Asc.
image

Desc.
image

I understand that an empty field is not a number, therefore it probably is not accounted for in sorting but this is not expected behaviour for me. It has some inpracticalities, for example when I have a large list with dates and I need to make sure all rows have a date. I need to scroll to the very end of the list to see which ones are empty.

Any insights into this are much appreciated!

@josh any insights into this?

The current behavior is that empty fields always sort at the end of the list, whether the sort is in ascending order or descending order. We may build a feature at some point to let you decide how to sort them, since as you point out, there are situations where it’s preferable for empty fields to sort at the top. However, it’s not on the top of our list of things to support. For now, you can work around this limitation by merging two searches, one with just empty fields, and then another one with empty fields filtered out.

3 Likes

Ok, thanks for the tip

@Bubble, any idea when this will be looked at again? I tried to sort on a count of a list of things field recently and thought I was losing it when it was clearly not possible. I was sure I had done it in the past and even found a forum post by someone else where they did the same. I then tracked down this announcement.

I may be wrong but it seems to me that my case does not necessarily fall in either of the two categories outlined by @josh in this post. To be clear, let’s say I have a thing called Post, with a field called Likes, which is a list of users. I want to sort a RG of Posts by the count of Likes. This is purely a count, which evaluates to a number and used to work just fine for sorting. It therefore seems to me that the baby was kind of thrown out with the bathwater here, where even the bits that did work were removed.

Just a thought, if the full custom-type field/list capabilities are not ready to be restored, is it at least possible to add a sort type of count which lets you select custom-type field? I know one can work around this by adding a dedicated count field that you then have to maintain, but it just seems rather long-winded for what feels to my untrained eye to be a simple/standard feature, especially given that it used to work just fine.