Clojurians Log v2
pathom
EQL seems more fragile than it should be, so I’m wondering if I’m doing something wrong. Essentially I’m obtaining a vector of lookup keys (one resolver), but if just one of those keys doesn’t return info (another resolver), then I get bupkis… Or rather an error stating that the query failed (`Graph execution failed: Required attributes missing:`). So even if it pulls in 20 keys, and 19 lookups with one nil result, it kills the whole thing, I just want the query to finish with the nil. I’m returning the lookups in the format {:output nil :lookup-key “that-was-unsuccessful”}… Actually including the lookup key as well, so shouldn’t that work?
in your query you probably need to mark a key as optional with pco/? . though I'm a little fuzzy on what exactly you're returning, so there may or may not be additional things you need to tweak.
It’s not a key that null, it’s the returned value.
To allow your query to complete with nil values instead of throwing errors, try enabling lenient mode by setting p.error/lenient-mode? in the env
@jonas.rodrigues Thanks, that’s more like what I want. I’m surprised though that nil is treated as an error, though.
Thanks all, I found I did have a bug instead of {:output nil} I was returning simply nil in this case. doh!
In regard to implementing batching, I see https://pathom3.wsscode.com/docs/resolvers#resolver-transform,
; note in practice there is usually no reason to do this, since processing as a batch
; is not more efficient than letting Pathom do it
the example mentioned in the docs is related to a resolver that is more computationally bound (instead of IO), in that case its better to not batch
generally batching is recommended when you can improve the IO (for instead, instead of reaching for N API calls or N database requests)
So if all my batching code did is to spawn futures (for blocking I/O) that also would not be an improvement on what Pathom already does as well.
I’m also wondering about this in the context of limit/take. That I presume might be a reason to implement it myself?
if you spawn futures, you need to make sure the overhead of spawning them isn't greater than the work they are accomplishing (for instance, if its a simple calculation, the creation of a future could be much slower than just running the computation)
limit/take is more about pagination than batching, if you split your request in multiple limit/take to run all at once, its probably better to just run all at once and let the database handle it
one feature that Pathom gives to you regarding batching is chunking, which can be useful in the context of API's that limit the amount of batching you can do at once
for that you can set the config ::pco/chunk-size 50 for example ,to batch in chunks of 50
In my case, I’m using a key/value store, so the DB doesn’t handle the limit. I would need to know how many had been fetched to do a limit, so it would seem I need to implement the batching.
Unless I suppose I could know how many had been fetched.