ORDERBY() as part of a slice

[MultiTech]

I’m finding myself having to repeat an ORDERBY() for a slice over and over again - I can’t help but think of all the cycles wasted in this repetition during sync/calculation.

If I had the ability to order the rows of a slice AT THE SLICE LEVEL - then I wouldn’t need to worry about the sort order for any of my views, when using any formulas I know the rows will be in the order I’m expecting, etc.

---

The same could be said for regular data sources as well - being able to order rows at the table level would be handy; again, one-and-done.

As always, thanks for considering!

[GreenFlux]

Great idea! It would also be awesome if the list of keys generated by REF_ROWS had a default sort order.

[MultiTech]

@GreenFlux you can actualy use ORDERBY() with REF_ROWS

Here’s an example from an app I’m working on:

orderby(REF_ROWS("Page_Elements", "Walkthrough_Link"), 
  [Element_Column_Name], false,
  [EditDateTime], true
)

This puts my refrows in the correct order, and from here I’m able to work off that assumption.
This is one example of where I’m using orderby() over and over, so being able to establish something as a “hard code” would be awesome.

[MultiTech]

GreenFlux:

It would also be awesome if the list of keys generated by REF_ROWS had a default sort order.

Coming back to this again. @praveen is this anywhere on the radar? This would REALLY make a lot of advanced things much easier.

1. We wouldn’t have to setup the sort in the view, it’s taken care of in the list
2. We can make assumptions based on the sorting we’ve established; things like:
   • INDEX([Related Child_Records], 1)
   • If I know the sort order, this is either the first record created or the last
     • a MUCH more efficient way of finding the MaxRow() or MINROW() - even if it is a hack
3. and other advanced things that wouldn’t make sense to most.

---

Also, having the sort built into the virtual columns type would remove the neccessity of wrapping ORDERBY() around things.

Which I’ve just discovered now causes the auto-ref set to fail:

Wrapping an ORDERBY() around a Ref_Rows() causes the inline "New" button to loose it's context Questions

By default, when you have a Ref_Rows() formula this creates an inline view with a “New” button that allows you to create related records. When you tap the new button, the reference context is carried over into the following form (automatically creating the reference link). But if you wrap an ORDERBY() formula around that ref_rows, the relation is no longer carried over - you have to manually select the reference record. In fact, it seems that any modifications to the Ref_rows causes the auto-…

Thanks!

[aucforum]

AppSheet is supposed to be (less) no code in philosophy.

This would save the need to code more expressions in other parts of AppSheet were we currently have to.

[MultiTech]

Over a year later… and I’m coming back to this one again…

@praveen: this is one of those “Quality of Life” type updates that would go a really long way in making things easier

Allow me to explain a bit: because we can’t sort from the Slice-side of things, if I want that list in the proper order:

1. We have to include an OrderBy() or Sort() inside the list column (like a Ref_Rows() )

   • But this then causes the “Default Reverse Reference” - that is, the reverse reference created by the system automatically when you create a reference column - to regenerate itself

   • Which means we either have:

     • an extra [Related Whatever] column that we’ve nulled out with list(); or:
     • an extra virtual column that we’ve taken the original [Related Whatever] and wrapped that in an OrderBy().

The effect is still having 2 columns for 1 thing

or…

2. We have to include an ORDERBY() or SORT() inside every formula pulling the list

   • EVERY formula pull will need to include the ordering part

---

Including the ability to sort from the Slice would remove all of this, as the “source” would be in the correct order already.

[MultiTech]

Additionally… having the ability to sort a slice would bring about ways in which to remove the use of MaxRow() or MinRow().

• Largely when someone’s using one of those formulas, they’re needing to find “the last ‘whatever’ created today” - for example

In order to acccomplish that in my data, I have two primary paths:

1. Use MaxRow(Table, CreationDate, and([CreationDate = TODAY(), [Status] = “Open”))
   • In which case, that formula - essentially a port for a brute-force SELET() - will run on each record.
     • And if I’ve got a table with 10,000 rows… that’s a lot of SELECT() work

or…

2. Create a data-subset using a (slice), order that, and pull the last one
   • In which case I create a slice using the conditions from the MaxRow() formula, so it holds the set of records I need
     • Then ordering that list by CreationDate
     • Then using Index(Slice[RecordID], Count(Slice[RecordID])) to pull the last item from the list

If I had the ability to sort the slice… then I wouldn’t need the “order that” part, and instead I could simply INDEX() the last one out of the list.

• Surely INDEX() would be faster/more-efficient than MaxRow()
  • Even if I ran that MaxRow() on the slice I created… I would think.

[Marc_Dillon]

I don’t even remember voting for this one, but apparently I already had. Great suggestion.

[Rifad]

I support this. Any news on it?

[Rifad]

Implementing a custom slice sort order is beneficial for situations like this. It's essential to present data effectively all the time. Our user interface requires greater customization options akin to this example.

Sorting by column is functional, but sorting at a multi-column level across various child tables poses challenges. A potential solution might be to use a sort column that encompasses various scenarios, assigning them specific rankings. However, the ability to sort by slicing would greatly enhance the capabilities and applicability of our use cases. 

In both scenarios mentioned earlier, it's evident that implementing the same functionality necessitates multiple views. This is due to the user experience sort feature being limited to single-column sorting and nested sorting only.