d/q and d/query are eager and cannot deliver partial results. The only thing you can do is set a timeout, which will keep it from running forever but won’t give you results if it is exceeded. If you want partial results, use d/datoms, d/seek-index, d/index-pull etc. You can also use d/q but supply it chunks of input. (update: I thought you were asking about datomic! please ignore)

Maybe you could add an atom in the query env. The moment one resolver finds something you update it. Other resolvers either dont start or cancel whatever they are doing (via add-watch). Just a vague idea, no idea if feasible

Im a bit confused here, is this a pathom question or a #C03RZMDSH question?

if its in the pathom context, are we talking about a single attribute, or multiple attributes?

Oh man I assumed it was a datomic question, somehow I missed the channel name. My answer is for datomic. Sorry for the confusion!

Yes, it was pathom question, thanks for the pointer @U0FT7SRLP

I would be careful with the atom approach, make sure you are not sharing the atom across requests, otherwise you might stop running unrelated requests

you can use a plugin to inject an atom, but I still wonder what is the problem you are trying to solve

Simply performance.

I think this may fall into the batch processing, I need to take a look at that.

but what are you trying to resolve? its a thing cross attributes? a single attribute?

because Im hearing so far is things should handle automatically, so I guess Im missing something

Basically a list that needs to do a look-up for each item in the list, but once it finds a match, it doesn’t need to continue.

indeed I think its something you can handle with some work on top of batch resolvers, since there you control the load of the list as a whole

but I like to warn you of some implications, like, if you get in a more complex situations and the data is needed for something outside that list, you might end up with missing data

I say that because in Pathom 3, the batch is across your whole query (not just a single list), so you have that same need spread across different parts of the query, that still going trigger a single call to the batch resolver

Ah, that makes sense, good to know.