Make the DataLoaderRegistry use a supplier pattern about java-dataloader HOT 5 CLOSED

Wouldn't this fix be a breaking change?

from java-dataloader.

A non-breaking enhancement would be to add an optional field dataLoaderFactory to the DataLoaderRegistry.
This data loader factory, if set, would then be used in the getDataLoader function to act as the supplier of the required data loaders "on the fly" in case there is no such dataloader yet.
In the simplest, just a map of possible DL keys and their corresponding suppliers could serve as such factory.

from java-dataloader.

An example: Inego@1c18495

from java-dataloader.

In fact, there's a simpler/cleaner solution without an overhead for those who need this lazy behavior:

master...Inego:lazy-dl-registry

The usage would be as simple as:

// Prepare the singleton factory once...
LazyDataLoaderFactory factory = new LazyDataLoaderFactory();
        
factory.register("clients", () -> new ClientDataLoader());
factory.register("products", () -> new ProductDataLoader());

// ... and create a lazy registry for every request
LazyDataLoaderRegistry registry = factory.createRegistry();

from java-dataloader.

I looked into this and its really kinda pointless.

We can make it lazy but as soon as you called dispatchAll the it needs to materialise the dataloaders and dispatch them

We would have to write a fancy MemoizingSupplierWithTracking that could decide if its every been asked for and then filter them out from the list. In short I am not sure that its worth it.

I would love to see more evidence now of the costs of creating a DL even if its not needed in a certain graphql request.

from java-dataloader.