Very advanced dynamic of a PageArray with "sorting decisions" in every item – how to do?

[marcus]

Hi y'all! ?

long time no hear (and it's all my fault - I haven't been to the forums for quite a while). Anyway, I got a complex question that as of right now, feels way above my skills. But I'll try to describe it, and I'm hoping to describe things in a way that's comprehensible:

As it reads in the title, what's in front of me is a complex situation and a codebase I inherited.

1. In its core, its about dynamic sorting. With dynamic sorting I mean two things:
   1. The field being sorted by is depended on user input AND a programmatical determined decision. More details follow below
   2. It's not as simple as sorting by `created_at`, for example.
2. So I got a collection of templates in a PageArray. All of the items are being output using a loop (paginated, and so on). So far, so simple.
3. Every item of this collection is of the same template. This template has a bunch of fields associacted with it, with numeric values. Let's simplify the situation for the sake of explaining and say that these fields can be grouped into certain clusters.
4. In a template, a user can filter for certain (by using selects, which, upon change, change the URL). So that every filtered state is accessible unter its own URL.
5. A user also has the opportunity to sort, and this is kind of where the field clusters come into play. Also, the selected sort mode is persisted in the URL, by a get parameter, for example ?sort=cluster1. Of course, both filter states and sort states are "mirrored" in the URL, so that every of these states can be accessible under its own URL.
6. Going back to point 3: for all of the fields (in the clusters) there is a field counterpart which stores the inverted value of the field (in reality, this isn't the inversion but something more complicated - but for the sake of explaining, I'll describe it that way)
7. Now, based on both sorting and filter settings (see 4. and 5.) a decision must be made whether the non-inverted or the inverted field should be used for sorting the whole connection.

My questions:

• How would you solve this? My plan for today is to do a little proof of concept with runtime fields: Right after I got the user data regarding sorting and filtering I have all the data I need to decide whether to use a field or its inverted counterpart for sorting. I'm planning to create runtime fields in which I store the "decision" I'm now able to make (which value, the original or inverted field value I should use for sorting).
• The central query of getting the PageArray, filtering and sorting it is a rather complex one. In the code I inherited this query is built by modifying a large string that consists of data from the interface (regarding filtering and sorting). Only after every user settings is "read" this string gets passed as a rather sophisticated selector into a $page→find($complexQuery) API call. While experimenting I found out that it appears that runtime fields are not really considered in this approach (but maybe I'm doing things wrong). Should I instead leave the approach of trying to build it with the API and go for building a raw DB query instead?

Is there an simple and obvious solution to the problem I described that I'm not able to see?

Anyway, thanks a bunch!

marcus

[BillH]

I'm not sure that I fully understand what you need to do, but I have a couple of thoughts.

One is that runtime fields and searches won't mix well, and if you need to maintain a field for some kind of sort code, you'd be better off hooking on saveReady to maintain a field.

The other is that it can be quicker than you expect to loop through the results of a search (so long as there aren't huge numbers). So a good strategy might be to get as few pages as possible using selectors, and then loop through those pages to produce the final result.