Provide a way to have batch loaders that return Map

[ceronman]

Hello,

I have been using java-dataloader for some time now and I found it very useful. Here is one small feedback:

I find the current BatchLoader functional interface is often inconvenient:

CompletionStage<List<V>> load(List<K> keys)

The input is a list of keys and the output is a list that has to match 1 to 1 with the list of keys. In real world data fetching scenarios, it's rare to do a query that returns 1 to 1 matches. For example, let's assume that I want to load Users from a database, I could probably use a query that looks like this:

SELECT * FROM User WHERE id IN (keys)

This kind of queries are very common when using batch loaders, however, this won't return a 1 to 1 match. If one of the users does not exist, the result will not contain it. This means that in order to use this query in a BatchLoader, I have to first create a map, and then return a List of that crossed with the original keys. For example:

List<User> users = database.query("SELECT * FROM User WHERE id IN keys");
Map<Integer, User> userByKey = users.stream().collect(toMap(User::getId, Function.identity()));
List<User> result = keys.stream().map(userByKey::get).collect(toList());
return result;

I think all this bolier plate code can be reduced if an alternative BatchLoader is provided that returns a Map instead:

CompletionStage<Map<K, V>> load(List<K> keys)

What do you think?

[bbakerman]

The map MUST still be the same size as the number of keys supplied. The reason for this is that they inner workings use a list of keys to map to a list of completable futures of values by those keys.

if the 2 dont match in size, we are kinda stuffed

[ashu-walmart]

It is my understanding that in addition to the exact length of list of values , it should also be in exact encounter order? Is that true? Can that be implicit requirement eliminated by using a Map?
https://github.com/graphql-java/java-dataloader/blob/master/src/main/java/org/dataloader/DataLoader.java#L315

for(int idx = 0; idx < queuedFutures.size(); ++idx) {
                Object value = values.get(idx);
                CompletableFuture<V> future = (CompletableFuture)queuedFutures.get(idx);

[bbakerman]

in addition to the exact length of list of values , it should also be in exact encounter order? Is that true?

yes that is true. The reason is 2 fold, 1) it needs a way to go from completed value back to completed key and 2) it was how Facebook write it originally and I kept those semantics.

Remember is needs a way to go from a value CompletableFuture finishing back to a key. Off hand I think we can do that with a Map but honestly it was more driven by being similar to the original JavaScript implementation.

[bbakerman]

There is new PR up to handle this issue

[bbakerman]

This has been added in 2.1.1