Clojurians Log v2

I’m struggling with a design problem in lacinia that I wonder if others have encountered. I want to be able to provide a reasonable default sort order for my list values. In the common case where these are lists of maps, and those maps are populated by resolvers which run after the list resolver, and I’m not e.g. pre-populating those maps using the hints from selections-tree… it’s not clear where the best place to hang the sort is. My best thought at the moment is to add the sorter fn as metadata on the list and apply all such sorters after all resolvers have finished, perhaps in a pedestal interceptor, but I’m not sure that the metadata will actually convey. Perhaps there are other approaches I have not yet considered?

@donaldball Isn't the list resolver returning a list of objects (maps, in this case) that are then individually resolved? Why can't the list resolver just sort the list? In other words, why are the maps populated in the list item resolvers instead of in the list resolver itself?

In a specific case in my resolvers, the top-level resolver is returning a list of datomic entity ids for which each lower-level resolver obtains the attribute value. While I could rearrange that to take advantage of the selections tree and pull everything at once, in the more general case, an object may be constituted from data pulled from different underlying databases and resolvers. It feels like I’m fighting the lacinia recursive resolver model if I force my list resolver to ensure that the maps are fully populated (or at least fully populated enough to sort).

I see, that makes sense. Unfortunately, I don't have a good suggestion about that at this time. 🤷

It's not ideal, but perhaps doing the sorting from a Pedestal interceptor outside of Lacinia might get the job done. It does feel like there may be a need for slightly more lifecycle than just a :resolve function, I've been looking at a callback to prepare a raw value for selection, and you have an interesting case that perhaps would take place after a list field has resolved and recursively selected.

Unfortunately, it does not seem that lacinia conveys metadata 😕 e.g. on my sequential values. Is there an alternate approach that might work, or might someone be able to point me towards the bit within lacinia where such transformations are taking place? (I suspect it’s in same area that the ordered-map overlay is occurring…)

Another possibility that comes to mind is providing the sorter or the data from which a sorter can be derived in extensions or in the context, but that would seem to require that I be able to obtain from the context in a resolver the key path (e.g. the argument to get-in in which the resolver’s data will be stored) so that I can find the sequential data in question later. Is that information available?