That project on forge is mine, and I think it can also be implemented in scaffolding for lists.

I wonder whether this is the way to go for large data sets. Apparently (see here and here) there is an increasing performance penalty as one accesses "pages" closer to the end of the result set. An alternative is to apply the "seek method" (see here for more details). There's a discussion going on this topic in the forum. Follow it here.

Hi Everyone

Came up on this problem recently on the aggregates. I understand the OFFSET-NEXT performance penalty when compared to the Seek method, but I still think that this should be implemented on the Aggregate's optimized SQL, as it is sure to have better performance than the 'Select TOP (n)'  that is being currently used. That will lead to even worse performance as a user browses further back since it will bring more and more records from the query. 

@OutsystemsTeam any updates on this (IMHO) excellent idea?

Regards,

   CLSJ

We've cases that low performance is notable and our databases still growing up.

Then OFFSET-NEXT can turn pain less.

Something like this is implemented in Reactive Web Apps:

Start Index in Screen Aggregates for Pagination

Use the server-side pagination feature of the Screen Aggregates to build faster apps that need to handle large data sets. Enter the Start Index and fetch the number of records you define in Max Records.

added the idea for traditional web apps, because it's very much needed/wanted for pagination in web services!

Hi J,

Will you please include a link in your final post, to your traditional web apps idea.

Thanks

Albert

@J. , @Tiago Simões  was this idea for traditional apps ever implemented? 

I needed this idea as a way to OFFSET and  go through records and update records from where I left off via a loop in a server action (not present the data through a screen and use pagination) 

@Tiago Simões

Was this idea ever implemented for server side logic?

I'm implementing a REST API that I need to paginate the results...