Brad Baker
Brad Baker
Can you go into more details on why you need this?
Linekd with https://github.com/graphql-java/graphql-java/pull/2925
A quick update on this issue - see the PR for the messy details We discovered that that the `Instrumentation` code needs to be substantially changed to work with subscriptions...
Starting benchmark : ``` Benchmark Mode Cnt Score Error Units IntrospectionBenchmark.benchMarkIntrospection avgt 15 0.608 ± 0.045 s/op ``` After this change ``` Benchmark Mode Cnt Score Error Units IntrospectionBenchmark.benchMarkIntrospection avgt...
@jord1e > this wouldn't disable any validation right, or would it? No - this does the same amount of processing as usual. The saving here is that we don't create...
Nominally this PR does indeed solve the composition of data loader calls - the problem is it does it in such a way that negates the benefits of batching. This...
Currently we dont have a way to do what you are after. CompleteableFutures give us no way to know how deep they are nested and hence how many times dispatch...
For the record just dispatching until the depth is
See `org.dataloader.registries.ScheduledDataLoaderRegistry` in the lastest 3.x versions for some of the answers to the above It allows the DataLoader to "tick" in the background and decide if it is going...
> This works to unstuck nested data loaders, at the cost of naively triggering dispatches too early for long running data loading tasks. This is pretty much how the JS...