DataLoaderPhp is a generic utility to be used as part of your application's data fetching layer to provide a simplified and consistent API over various remote data sources such as databases or web services via batching and caching.

Overview

DataLoaderPHP

DataLoaderPHP is a generic utility to be used as part of your application's data fetching layer to provide a simplified and consistent API over various remote data sources such as databases or web services via batching and caching.

GitHub Actions Code Coverage Latest Stable Version

Requirements

This library requires PHP >= 7.3 to work.

Getting Started

First, install DataLoaderPHP using composer.

composer require "overblog/dataloader-php"

To get started, create a DataLoader object.

Batching

Batching is not an advanced feature, it's DataLoader's primary feature. Create loaders by providing a batch loading function.

use Overblog\DataLoader\DataLoader;

$myBatchGetUsers = function ($keys) { /* ... */ };
$promiseAdapter = new MyPromiseAdapter();

$userLoader = new DataLoader($myBatchGetUsers, $promiseAdapter);

A batch loading callable / callback accepts an Array of keys, and returns a Promise which resolves to an Array of values.

Then load individual values from the loader. DataLoaderPHP will coalesce all individual loads which occur within a single frame of execution (using await method) and then call your batch function with all requested keys.

load(2) ->then(function ($user) use ($userLoader) { return $userLoader->load($user->invitedByID); }) ->then(function ($invitedBy) { echo "User 2 was invited by $invitedBy"; }); // Synchronously waits on the promise to complete, if not using EventLoop. $userLoader->await(); // or `DataLoader::await()`">
$userLoader->load(1)
  ->then(function ($user) use ($userLoader) { return $userLoader->load($user->invitedByID); })
  ->then(function ($invitedBy) { echo "User 1 was invited by $invitedBy"; });

// Elsewhere in your application
$userLoader->load(2)
  ->then(function ($user) use ($userLoader) { return $userLoader->load($user->invitedByID); })
  ->then(function ($invitedBy) { echo "User 2 was invited by $invitedBy"; });

// Synchronously waits on the promise to complete, if not using EventLoop.
$userLoader->await(); // or `DataLoader::await()`

A naive application may have issued four round-trips to a backend for the required information, but with DataLoaderPHP this application will make at most two.

DataLoaderPHP allows you to decouple unrelated parts of your application without sacrificing the performance of batch data-loading. While the loader presents an API that loads individual values, all concurrent requests will be coalesced and presented to your batch loading function. This allows your application to safely distribute data fetching requirements throughout your application and maintain minimal outgoing data requests.

Batch Function

A batch loading function accepts an Array of keys, and returns a Promise which resolves to an Array of values. There are a few constraints that must be upheld:

  • The Array of values must be the same length as the Array of keys.
  • Each index in the Array of values must correspond to the same index in the Array of keys.

For example, if your batch function was provided the Array of keys: [ 2, 9, 6, 1 ], and loading from a back-end service returned the values:

[
  ['id' => 9, 'name' => 'Chicago'],
  ['id' => 1, 'name' => 'New York'],
  ['id' => 2, 'name' => 'San Francisco']  
]

Our back-end service returned results in a different order than we requested, likely because it was more efficient for it to do so. Also, it omitted a result for key 6, which we can interpret as no value existing for that key.

To uphold the constraints of the batch function, it must return an Array of values the same length as the Array of keys, and re-order them to ensure each index aligns with the original keys [ 2, 9, 6, 1 ]:

[
  ['id' => 2, 'name' => 'San Francisco'],
  ['id' => 9, 'name' => 'Chicago'],
  null,
  ['id' => 1, 'name' => 'New York']
]

Caching (current PHP instance)

DataLoader provides a memoization cache for all loads which occur in a single request to your application. After ->load() is called once with a given key, the resulting value is cached to eliminate redundant loads.

In addition to relieving pressure on your data storage, caching results per-request also creates fewer objects which may relieve memory pressure on your application:

$userLoader =  new DataLoader(...);
$promise1A = $userLoader->load(1);
$promise1B = $userLoader->load(1);
var_dump($promise1A === $promise1B); // bool(true)

Clearing Cache

In certain uncommon cases, clearing the request cache may be necessary.

The most common example when clearing the loader's cache is necessary is after a mutation or update within the same request, when a cached value could be out of date and future loads should not use any possibly cached value.

Here's a simple example using SQL UPDATE to illustrate.

query($sql)) { $userLoader->clear(4); } // Later the value load is loaded again so the mutated data appears. $userLoader->load(4)->then(...); // Request completes.">
use Overblog\DataLoader\DataLoader;

// Request begins...
$userLoader = new DataLoader(...);

// And a value happens to be loaded (and cached).
$userLoader->load(4)->then(...);

// A mutation occurs, invalidating what might be in cache.
$sql = 'UPDATE users WHERE id=4 SET username="zuck"';
if (true === $conn->query($sql)) {
  $userLoader->clear(4);
}

// Later the value load is loaded again so the mutated data appears.
$userLoader->load(4)->then(...);

// Request completes.

Caching Errors

If a batch load fails (that is, a batch function throws or returns a rejected Promise), then the requested values will not be cached. However if a batch function returns an Error instance for an individual value, that Error will be cached to avoid frequently loading the same Error.

In some circumstances you may wish to clear the cache for these individual Errors:

$userLoader->load(1)->then(null, function ($exception) {
  if (/* determine if error is transient */) {
    $userLoader->clear(1);
  }
  throw $exception;
});

Disabling Cache

In certain uncommon cases, a DataLoader which does not cache may be desirable. Calling new DataLoader(myBatchFn, new Option(['cache' => false ])) will ensure that every call to ->load() will produce a new Promise, and requested keys will not be saved in memory.

However, when the memoization cache is disabled, your batch function will receive an array of keys which may contain duplicates! Each key will be associated with each call to ->load(). Your batch loader should provide a value for each instance of the requested key.

For example:

$myLoader = new DataLoader(function ($keys) {
  echo json_encode($keys);
  return someBatchLoadFn($keys);
}, $promiseAdapter, new Option(['cache' => false ]));

$myLoader->load('A');
$myLoader->load('B');
$myLoader->load('A');

// [ 'A', 'B', 'A' ]

More complex cache behavior can be achieved by calling ->clear() or ->clearAll() rather than disabling the cache completely. For example, this DataLoader will provide unique keys to a batch function due to the memoization cache being enabled, but will immediately clear its cache when the batch function is called so later requests will load new values.

$myLoader = new DataLoader(function($keys) use ($identityLoader) {
  $identityLoader->clearAll();
  return someBatchLoadFn($keys);
}, $promiseAdapter);

API

class DataLoader

DataLoaderPHP creates a public API for loading data from a particular data back-end with unique keys such as the id column of a SQL table or document name in a MongoDB database, given a batch loading function.

Each DataLoaderPHP instance contains a unique memoized cache. Use caution when used in long-lived applications or those which serve many users with different access permissions and consider creating a new instance per web request.

new DataLoader(callable $batchLoadFn, PromiseAdapterInterface $promiseAdapter [, Option $options])

Create a new DataLoaderPHP given a batch loading instance and options.

  • $batchLoadFn: A callable / callback which accepts an Array of keys, and returns a Promise which resolves to an Array of values.

  • $promiseAdapter: Any object that implements Overblog\PromiseAdapter\PromiseAdapterInterface. (see Overblog/Promise-Adapter)

  • $options: An optional object of options:

    • batch: Default true. Set to false to disable batching, instead immediately invoking batchLoadFn with a single load key.

    • maxBatchSize: Default Infinity. Limits the number of items that get passed in to the batchLoadFn.

    • cache: Default true. Set to false to disable caching, instead creating a new Promise and new key in the batchLoadFn for every load.

    • cacheKeyFn: A function to produce a cache key for a given load key. Defaults to key. Useful to provide when an objects are keys and two similarly shaped objects should be considered equivalent.

    • cacheMap: An instance of CacheMap to be used as the underlying cache for this loader. Default new CacheMap().

load($key)

Loads a key, returning a Promise for the value represented by that key.

  • $key: An key value to load.
loadMany($keys)

Loads multiple keys, promising an array of values:

list($a, $b) = DataLoader::await($myLoader->loadMany(['a', 'b']));

This is equivalent to the more verbose:

list($a, $b) = DataLoader::await(\React\Promise\all([
  $myLoader->load('a'),
  $myLoader->load('b')
]));
  • $keys: An array of key values to load.
clear($key)

Clears the value at $key from the cache, if it exists. Returns itself for method chaining.

  • $key: An key value to clear.
clearAll()

Clears the entire cache. To be used when some event results in unknown invalidations across this particular DataLoaderPHP. Returns itself for method chaining.

prime($key, $value)

Primes the cache with the provided key and value. If the key already exists, no change is made. (To forcefully prime the cache, clear the key first with $loader->clear($key)->prime($key, $value). Returns itself for method chaining.

static await([$promise][, $unwrap])

You can synchronously force promises to complete using DataLoaderPHP's await method. When an await function is invoked it is expected to deliver a value to the promise or reject the promise. Await method process all waiting promise in all dataLoaderPHP instances.

  • $promise: Optional promise to complete.

  • $unwrap: controls whether or not the value of the promise is returned for a fulfilled promise or if an exception is thrown if the promise is rejected. Default true.

Using with Webonyx/GraphQL

DataLoader pairs nicely well with Webonyx/GraphQL. GraphQL fields are designed to be stand-alone functions. Without a caching or batching mechanism, it's easy for a naive GraphQL server to issue new database requests each time a field is resolved.

Consider the following GraphQL request:

{
  me {
    name
    bestFriend {
      name
    }
    friends(first: 5) {
      name
      bestFriend {
        name
      }
    }
  }
}

Naively, if me, bestFriend and friends each need to request the backend, there could be at most 13 database requests!

When using DataLoader, we could define the User type at most 4 database requests, and possibly fewer if there are cache hits.


use GraphQL\GraphQL;
use GraphQL\Type\Definition\ObjectType;
use GraphQL\Type\Definition\Type;
use Overblog\DataLoader\DataLoader;
use Overblog\DataLoader\Promise\Adapter\Webonyx\GraphQL\SyncPromiseAdapter;
use Overblog\PromiseAdapter\Adapter\WebonyxGraphQLSyncPromiseAdapter;

/**
* @var \PDO $dbh
*/
// ...

$graphQLPromiseAdapter = new SyncPromiseAdapter();
$dataLoaderPromiseAdapter = new WebonyxGraphQLSyncPromiseAdapter($graphQLPromiseAdapter);
$userLoader = new DataLoader(function ($keys) { /*...*/ }, $dataLoaderPromiseAdapter);

GraphQL::setPromiseAdapter($graphQLPromiseAdapter);

$userType = new ObjectType([
  'name' => 'User',
  'fields' => function () use (&$userType, $userLoader, $dbh) {
     return [
            'name' => ['type' => Type::string()],
            'bestFriend' => [
                'type' => $userType,
                'resolve' => function ($user) use ($userLoader) {
                    $userLoader->load($user['bestFriendID']);
                }
            ],
            'friends' => [
                'args' => [
                    'first' => ['type' => Type::int() ],
                ],
                'type' => Type::listOf($userType),
                'resolve' => function ($user, $args) use ($userLoader, $dbh) {
                    $sth = $dbh->prepare('SELECT toID FROM friends WHERE fromID=:userID LIMIT :first');
                    $sth->bindParam(':userID', $user['id'], PDO::PARAM_INT);
                    $sth->bindParam(':first', $args['first'], PDO::PARAM_INT);
                    $friendIDs = $sth->execute();

                    return $userLoader->loadMany($friendIDs);
                }
            ]
        ];
    }
]);

You can also see an example.

Using with Symfony

See the bundle.

Credits

Overblog/DataLoaderPHP is a port of dataLoader NodeJS version by Facebook.

Also, large parts of the documentation have been ported from the dataLoader NodeJS version Docs.

License

Overblog/DataLoaderPHP is released under the MIT license.

Comments
  • Add support for PHP 8

    Add support for PHP 8

    Resolves #40.

    • Minimal PHP version increased to 7.1. (So that supported versions are same as in webonyx/graphql-php. Going up to 7.2 would make things easier regarding PHPUnit.)
    • Installation on PHP 8 allowed.
    • composer check-platform-reqs added to build steps
    • PHPUnit bumped to ^7.5|^8.5 to support PHP 7.1-8.0
    • webonyx/graphql-php updated to the current version 14
    • --prefer-source used for composer update as tests/StarWarsData.php is no longer part of webonyx/graphql-php package. Alternative options would be to create a local copy of the file in this repository or download it from webonyx/graphql-php repo with wget in before_install.
    • The current version of php-cs-fixer (2.16) used, however, it doesn't allow installation on PHP 8 yet (see FriendsOfPHP/PHP-CS-Fixer#4702).
    • PHPUnit option convertDeprecationsToExceptions disabled to deal with deprecated GraphQL::execute() (related to #39).

    All looks good apart from maybe the most important thing - Travis CI doesn't support PHP 8 yet. PHP 8.0 is available under nightly version but contains an ancient version (PHP 8.0.0-dev (cli) (built: Jan 7 2020 22:28:03) ( ZTS )) so it can't be trusted.

    How do you want me to proceed? Should we wait for Travis CI? Or maybe migrate to Github Actions?

    opened by vhenzl 5
  • Added fix to wait if new instances of dataloader were declared during the processing

    Added fix to wait if new instances of dataloader were declared during the processing

    This fix solves the awaitInstances method for cases like this :

    $dataloader->load(1)->then(function () {
        $subLoader = new DataLoader(...);
        $subLoader->load(2);
    });
    

    Without the fix, awaitInstances() would stop on the first dataloader, ignoring the second one.

    opened by OwlyCode 5
  • Incompatibility with experimental Executor

    Incompatibility with experimental Executor

    Related to https://github.com/webonyx/graphql-php/issues/397.

    Webonyx 0.13 has a new experimental (but faster) Executor implementation. However it seems that the custom promise adapter from this package is not compatible with it. When they are used together, some resolve functions get a GraphQL\Executor\Promise\Promise as their first parameter instead of the resolved value.

    opened by enumag 4
  • Error when doing a GraphQL request:

    Error when doing a GraphQL request: "Cannot change rejection reason"

    Hello,

    When I try to execute a request in production environment, I'm experiencing this issue:

    {"code":500,"message":"Internal Server Error"}<br />
    <b>Fatal error</b>:  Uncaught Exception: Cannot change rejection reason in /my/local/directory/poc/vendor/webonyx/graphql-php/src/Executor/Promise/Adapter/SyncPromise.php:63
    Stack trace:
    #0 /my/local/directory/poc/vendor/overblog/dataloader-php/src/DataLoader.php(418): GraphQL\Executor\Promise\Adapter\SyncPromise-&gt;reject(Object(RuntimeException))
    #1 /my/local/directory/poc/vendor/overblog/dataloader-php/src/DataLoader.php(367): Overblog\DataLoader\DataLoader-&gt;failedDispatch(Array, Object(RuntimeException))
    #2 /my/local/directory/poc/vendor/overblog/dataloader-php/src/DataLoader.php(349): Overblog\DataLoader\DataLoader-&gt;dispatchQueueBatch(Array)
    #3 /my/local/directory/poc/vendor/overblog/dataloader-php/src/DataLoader.php(225): Overblog\DataLoader\DataLoader-&gt;dispatchQueue()
    #4 /my/local/directory/poc/vendor/overblog/dataloader-php/src/DataLoader.php(297): Overblog\DataLoader\DataLoader-&gt;process()
    #5 /my/local/directory/poc/vendor/over in <b>/my/local/directory/poc/vendor/webonyx/graphql-php/src/Executor/Promise/Adapter/SyncPromise.php</b> on line <b>63</b><br />
    

    Something happens in the destruct function, but I have no idea why. Is it configured wrongly ?

    When I debug, the message passed into the exception GraphQL\Error\Error is DataLoader destroyed before promise complete..

    Everything works fine without the loader. My end to end tests are green with the dataloader (and it's disturbing...).

    My graphql configuration is:

    overblog_dataloader:
        defaults:
            promise_adapter: "overblog_dataloader.webonyx_graphql_sync_promise_adapter"
            options:
                batch: true
                cache: true
                max_batch_size: 100
                cache_map: "overblog_dataloader.cache_map"
    
        loaders:
            users:
                alias: "attribute_dataloader"
                batch_load_fn: "@pim_research.infrastructure.persistence.database.cached_attribute_repository:withCodes"
    

    My type declaration:

        pim_research.infrastructure.delivery.api.graphql.type.family_type:
            class: '%pim_research.infrastructure.delivery.api.graphql.type.family_type.class%'
            arguments:
                - '@pim_research.infrastructure.delivery.api.graphql.types'
                - '@pim_research.infrastructure.persistence.database.cached_attribute_repository'
                - '@attribute_dataloader'
            tags:
                - { name: 'pim_research.infrastructure.delivery.api.graphql.type' }
            lazy: true
    

    and my class:

    class FamilyType extends ObjectType
    {
        public function __construct(Types $types, AttributeRepository $attributeRepository, DataLoader $attributeDataLoader)
        {
            $config = [
                'name' => 'family',
                'description' => 'Family',
                'fields' => function() use ($types) {
                    return [
                        'code' => Type::string(),
                        'attributes' => Type::listOf($types->get(AttributeType::class))
                    ];
                },
                'resolveField' => function(Family $family, $args, $context, ResolveInfo $info) use ($attributeRepository, $attributeDataLoader) {
                    switch ($info->fieldName) {
                        case 'code':
                            return $family->code()->getValue();
                        case 'attributes':
                            return $attributeDataLoader->loadMany($family->attributeCodes());
                            //return $attributeRepository->withCodes($family->attributeCodes());
                        default:
                            return null;
                    }
                }
            ];
            parent::__construct($config);
        }
    }
    

    My dependency versions:

    "webonyx/graphql-php": "v0.11.2"
    "overblog/dataloader-php": "v0.5.2"
    "overblog/dataloader-bundle": "v0.4.0"
    

    Thanks.

    opened by ahocquard 4
  • Naming confusion

    Naming confusion

    The Interface naming generates a knot in my head everytime I want to do something, even though I understand the inner working of the two:

    • Overblog\PromiseAdapter\PromiseAdapterInterface
    • GraphQL\Executor\Promise\PromiseAdapter

    The first is used to promise the IDs, while the second is then'd with all ids to resolve the final data usind the batch load callback. Or is it not?

    All the overblog related packages are very helpful, but regarding the naming I always get knots in my head ;(

    The second comes from the webonyx project and makes sense. It is an interface for a promise based result. The first should maybe indicate it being an aggregate or higher order or collector promise (something that direction)?

    I know, naming things is not easy :( .

    http://hilton.org.uk/blog/why-naming-things-is-hard

    opened by akomm 4
  • Correct use without deprecated `GraphQL::execute()`?

    Correct use without deprecated `GraphQL::execute()`?

    GraphQL::execute() has been deprecated many versions ago.

    There are two examples of how to use dataloaders with webonyx/graphql-php (I'm aware of):

    A test in this project:

    https://github.com/overblog/dataloader-php/blob/9a3be9096fd81bc33fe0a1fe6cfb7f2609cf5735/tests/Functional/Webonyx/GraphQL/TestCase.php#L84

    And https://github.com/mcg-web/sandbox-dataloader-graphql-php. But both use this deprecated API.

    What's the correct use without deprecated GraphQL::execute() (particularly in combination with the "native" SyncPromise)?

    GraphQL::executeQuery() can't be use as it internally always uses GraphQL\Executor\Promise\Adapter\SyncPromiseAdapter\SyncPromiseAdapter instance, not Overblog\DataLoader\Promise\Adapter\Webonyx\GraphQL\SyncPromiseAdapter instance set with GraphQL::setPromiseAdapter() and it's execution results in "GraphQL\Error\InvariantViolation: Could not resolve promise" error.

    Assuming from this comment, the whole use of GraphQL::setPromiseAdapter() should be considered deprecated and for all cases that don't use GraphQL\Executor\Promise\Adapter\SyncPromiseAdapter\SyncPromiseAdapter, GraphQL::promiseToExecute() should be used.

    Given these adapters:

    use Overblog\DataLoader\Promise\Adapter\Webonyx\GraphQL\SyncPromiseAdapter;
    use Overblog\PromiseAdapter\Adapter\WebonyxGraphQLSyncPromiseAdapter;
    
    $graphQLPromiseAdapter = new SyncPromiseAdapter();
    $dataLoaderPromiseAdapter = new WebonyxGraphQLSyncPromiseAdapter($graphQLPromiseAdapter);
    

    I see two possible solutions. Either:

    $promise = GraphQL::promiseToExecute($graphQLPromiseAdapter, $schema, $query /* ... */);
    $result = $graphQLPromiseAdapter->wait($promise);
    

    which kinda replicates what GraphQL::execute() does, or:

    $promise = GraphQL::promiseToExecute($graphQLPromiseAdapter, $schema, $query /* ... */);
    $result = DataLoader::await($promise)->toArray();    
    

    Is that correct? Both works and seems to work equally. Is there any real difference between them? Any pros and cons using one over the other?

    opened by vhenzl 3
  • How to ensure keys get mapped to the correct objects?

    How to ensure keys get mapped to the correct objects?

    Hi, I'm not sure if it's an issue or just a misunderstanding. Suppose we have the following query:

    {
      u1: user (id: 25) {
        id
      }
      u2: user (id: 30) {
        id
      } 
      u3: user (id: 20) {
        id
      }
    }
    

    And our batchLoadFn is something like this (Laravel):

    ...
    $userLoader = new DataLoader(function ($ids) use ($promiseAdapter) {
      $collection = User::whereIn('id', $ids)->get();
    
      return $promiseAdapter->createFulfilled($collection);
    }, $promiseAdapter)
    

    Since there's no key mapping between the collection items and the keys, this will give us the following incorrect result (the resulting user objects are in the wrong order):

    {
      "data": {
        "u1": {
          "id": "20"
        },
        "u2": {
          "id": "25"
        },
        "u3": {
          "id": "30"
        }
      }
    }
    

    How can i ensure the keys are mapped to correct objects?

    opened by KevinAsher 3
  • Problem with 1:N relation

    Problem with 1:N relation

    The problem is apparent even in the readme of this package:

    $userType = new ObjectType([
      'name' => 'User',
      'fields' => function () use (&$userType, $userLoader, $dbh) {
         return [
                'name' => ['type' => Type::string()],
                'bestFriend' => [
                    'type' => $userType,
                    'resolve' => function ($user) use ($userLoader) {
                        $userLoader->load($user['bestFriendID']);
                    }
                ],
                'friends' => [
                    'args' => [
                        'first' => ['type' => Type::int() ],
                    ],
                    'type' => Type::listOf($userType),
                    'resolve' => function ($user, $args) use ($userLoader, $dbh) {
                        $sth = $dbh->prepare('SELECT toID FROM friends WHERE fromID=:userID LIMIT :first');
                        $sth->bindParam(':userID', $user['id'], PDO::PARAM_INT);
                        $sth->bindParam(':first', $args['first'], PDO::PARAM_INT);
                        $friendIDs = $sth->execute();
    
                        return $userLoader->loadMany($friendIDs);
                    }
                ]
            ];
        }
    ]);
    

    Now if I ask for several users + their best friends it will work nicely. All best friends will be loaded together.

    {
      users {
        name
        bestFriend {
          name
        }
      }
    }
    

    However if I ask for several users + 5 friends for each user then the query SELECT toID FROM friends WHERE fromID=:userID LIMIT :first will be repeated separately for each user instead of making just one query. So the N+1 problem is not really gone, just more hidden.

    {
      users {
        name
        friends(first: 5) {
          name
        }
      }
    }
    

    How should I eliminate this behavior?

    opened by enumag 3
  • Remove unnecessary files from `lib/promise-adapter`

    Remove unnecessary files from `lib/promise-adapter`

    A follow-up to #41. The overblog/promise-adapter "package" in lib/promise-adapter isn't a real package. The code there is both tested and distributed together with the main code. Files like composer.json or .travis.yml aren't used and are outdated and can be removed safely.

    opened by vhenzl 1
  • Support for PHP 8

    Support for PHP 8

    The library should be updated to support PHP 8.

    Doing so, older PHP versions could be removed, tests for PHP 7.3 should be fixed (failing currently) and added for PHP 7.4. Also, dev dependencies should be bumped - webonyx/graphql-php v0.11 vs current v14.

    I'm happy to prepare a PR…

    opened by vhenzl 1
  • Context for fetching

    Context for fetching

    Hello. I need to load data from an elasticsearch instance. All is working fine, but my issue is about overfetching of data and not using it in response (for instance, querying for name field also reads a description field which is not needed actually).

    So I was thinking about something like a context for every load. The queue will be grouped by unique context values and requests will be made for each of it. In my case, the context will be the fields that I need.

    If this sounds ok, I can try a pull request. Or maybe there is another way if doing this which I'm not aware of.

    Thanks.

    opened by danut007ro 1
  • DataLoader::await resolves all loaders

    DataLoader::await resolves all loaders

    Hi, great job on the lib guys! It really does bring cool possibilities to PHP-driven apps :)

    Quite recently I started to look into possibilities to introduce DataLoader to a new kind of API introduced into my project. Whilst it fits really cool for the use case it does have one downside which I managed to resolve but perhaps it could be a good addition to the lib in general.

    In the project, I do have a couple of independently sourced loaders for different kinds of data - all of the loaders besides one return promises being resolved on the serialization/normalization process of the API response - and it generates a great result. Code is clean and the amount of backend/database roundtrips is significantly reduced. However, since I do have to resolve one loader's data in the runtime of generation of the response I use the DataLoaderInterface::await method - and the issue is that it resolves ALL the promises from all of the loaders. It's understandable of course that the method exists and it works how it does but in this very case instead of having x(amount of loaders - 1) + y(unique runtime resolutions) I end up with x*y roundtrips.

    As a workaround, I prepared a new extending interface implementing the non-static awaitSingle method. In the implementation instead of using Overblog\DataLoader\Promise\Adapter\Webonyx\GraphQL\SyncPromiseAdapter I use GraphQL\Executor\Promise\Adapter\SyncPromiseAdapter allowing to resolve only specific loader.

    Any thoughts on the topic? I could give it a try and prepare the appropriate implementation if this would sound like something you'd like to have in the solution :)

    opened by piotrkreft 0
  • Promise never triggered

    Promise never triggered

    I use the example here, but the promise returned by loadMany method never get triggered, why?

    class CustomerLoader {
    
       /**
         * @var WebonyxGraphQLSyncPromiseAdapter
         */
        private $promiseAdapter;
    
        public function __construct($promiseAdapter)
        {
            $this->promiseAdapter = $promiseAdapter
        }
    
     public function all(array $userIds)
        {
            $users = CSessionInfo::query()
                ->whereIn('id', $userIds)
                ->get()
                ->groupBy('id');
    
            $indexed = array_reduce($userIds, function($curry, $current) use($users) {
                 $curry[] = $users->has($current) ? $users->get($current): null;
                 return $curry;
            }, []);
    
            return $this->promiseAdapter->all($indexed);
        }
    
      public function getLoader()
        {
            return new DataLoader(function(array $userIds){
                $this->all($userIds);
            }, $this->promiseAdapter);
        }
    
       // this method is mapped to author field .
        public function resolveAuthor($parent)
        {
            return $this->getLoader()->load($parent['authorId']);
        }
    }
    

    $graphQLPromiseAdapter = new SyncPromiseAdapter(); $dataLoaderPromiseAdapter = new WebonyxGraphQLSyncPromiseAdapter($graphQLPromiseAdapter); $userLoader = new DataLoader(function ($keys) { /.../ }, $dataLoaderPromiseAdapter);

    GraphQL::setPromiseAdapter($graphQLPromiseAdapter);

    opened by videni 1
  • Argument 1 passed to GraphQL\Executor\Promise\Adapter\SyncPromiseAdapter::wait() must be an instance of GraphQL\Executor\Promise\Promise, instance of GuzzleHttp\Promise\Promise given, called

    Argument 1 passed to GraphQL\Executor\Promise\Adapter\SyncPromiseAdapter::wait() must be an instance of GraphQL\Executor\Promise\Promise, instance of GuzzleHttp\Promise\Promise given, called

    I think I discovered a bug in Dataloader.

    It has a static variable Dataloader::$instances where it keeps instances of itself. On __destruct the instance that destructs is taken out of the $instances array.

    I have now a weird situation where I run a full test suite that runs both functional tests and unit tests.

    First, a functional tests runs, and later I run a unit test that calls MyLoader::await($promise);.

    That one fails with this error:

    TypeError : Argument 1 passed to GraphQL\Executor\Promise\Adapter\SyncPromiseAdapter::wait() must be an instance of GraphQL\Executor\Promise\Promise, instance of GuzzleHttp\Promise\Promise given, called in /Volumes/CS/www/vendor/overblog/dataloader-php/lib/promise-adapter/src/Adapter/WebonyxGraphQLSyncPromiseAdapter.php on line 126
     /Volumes/CS/www/vendor/webonyx/graphql-php/src/Executor/Promise/Adapter/SyncPromiseAdapter.php:144
     /Volumes/CS/www/vendor/overblog/dataloader-php/lib/promise-adapter/src/Adapter/WebonyxGraphQLSyncPromiseAdapter.php:126
     /Volumes/CS/www/vendor/overblog/dataloader-php/src/DataLoader.php:282
     /Volumes/CS/www/tests/Infrastructure/GraphQL/Resolver/PlatformAccountResolverTest.php:60
    

    Somehow, the previous instance is not cleaned up nicely.

    How to solve this?

    opened by ruudk 0
  • Log activities to help profiling / debugging

    Log activities to help profiling / debugging

    As a Symfony developper, I want to develop a DataCollector to know more about our usage during development process.

    A dedicated DataLoaderLogger with logged get and cached activities could be used to develop such a DataCollector.

    • How many time keys have been fetched, with a ratio HIT / MISS.
    • How many batches have been executed to fetch data
    opened by armetiz 2
  • Returned data preconditions

    Returned data preconditions

    – The Array of values must be the same length as the Array of keys. – Each index in the Array of values must correspond to the same index in the Array of keys.

    This confused me, can you point me to part of code where I can examine this logic? Thanks!

    opened by simPod 2
  • Unable to run dataloader for simple example

    Unable to run dataloader for simple example

    I am really struggling to create even a simple version of this using the documentation.

    Here is my code:

    use GuzzleHttp\Promise\Promise;
    use Overblog\DataLoader\DataLoader;
    use Overblog\PromiseAdapter\Adapter\GuzzleHttpPromiseAdapter;
    
    class Sandbox
    {
        public function handle()
        {
            $myBatchGetUsers = function ($keys) {
                echo "Running myBatchGetUsers()...\n";
                $promise = new Promise();
                $promise->then(function ($value) {
                    echo "Running data promise..."; // never runs!
                    return [
                        ['name' => 'John'],
                        ['name' => 'Sara'],
                    ];
                });
                return $promise;
            };
    
            $promiseAdapter = new GuzzleHttpPromiseAdapter();
            $userLoader = new DataLoader($myBatchGetUsers, $promiseAdapter);
    
            $userLoader->load(4)
                ->then(function ($user) use ($userLoader) {
                    echo "{$user['name']}\n"; // never runs
                });
    
            $userLoader->load(5)
                ->then(function ($user) use ($userLoader) {
                    echo "{$user['name']}\n"; // never runs
                });
    
            $userLoader->await();
        }
    }
    

    The expected output is:

    Running myBatchGetUsers()...
    Running data promise...
    John
    Sara
    

    However the actual output is:

    Running myBatchGetUsers()...
    

    As you can see it is a very simple example, yet it does not work. What am I doing wrong?

    Many Thanks :-)

    opened by yahya-uddin 3
Releases(v0.7.0)
  • v0.7.0(Dec 7, 2021)

    What's Changed

    • Drop uncommon bin directory so vendor/bin is default by @simPod in https://github.com/overblog/dataloader-php/pull/46
    • Support only supported versions of PHP by @simPod in https://github.com/overblog/dataloader-php/pull/47
    • Add Github Actions CI by @simPod in https://github.com/overblog/dataloader-php/pull/48
    • Hide Licence badge by @simPod in https://github.com/overblog/dataloader-php/pull/49
    • Include StarWars fixture by @simPod in https://github.com/overblog/dataloader-php/pull/50
    • Cleanup tests by @simPod in https://github.com/overblog/dataloader-php/pull/51
    • Move CS to Github Actions by @simPod in https://github.com/overblog/dataloader-php/pull/52
    • Drop travis by @simPod in https://github.com/overblog/dataloader-php/pull/53
    • Make SyncPromiseAdapter compatible with webonyx master by @ruudk in https://github.com/overblog/dataloader-php/pull/56
    • Make PromiseInterface generic so it allows typing Promises by @simPod in https://github.com/overblog/dataloader-php/pull/57
    • Drop deprecated phpunit annotations by @simPod in https://github.com/overblog/dataloader-php/pull/55

    New Contributors

    • @simPod made their first contribution in https://github.com/overblog/dataloader-php/pull/46

    Full Changelog: https://github.com/overblog/dataloader-php/compare/v0.6.0...v0.7.0

    Source code(tar.gz)
    Source code(zip)
  • v0.6.0(Jan 13, 2021)

  • v0.5.3(Dec 15, 2018)

  • v0.5.2(Aug 18, 2017)

  • v0.5.1(Feb 17, 2017)

    v0.5.1 (2017-02-17)

    Fixed ignored instances when added during await() (#14 thank you @OwlyCode)

    This reproduces the fix of #8 for the new await() of the 0.5.0 version.

    Source code(tar.gz)
    Source code(zip)
  • v0.5.0(Feb 15, 2017)

    v0.5.0 (2017-02-15)

    Optimize DataLoader::await method (#13):

    DataLoader::await first tries to get the fulfilled value or the rejected reason directly from the promise otherwise calls promise adapter await to complete promise. Now DataLoader::await will not throw "no active dataLoader instance" exception when Promise entry is null.

    Source code(tar.gz)
    Source code(zip)
  • v0.4.0(Feb 9, 2017)

  • v0.3.0(Feb 7, 2017)

    v0.3.0 (2017-02-04)

    • Add promise adapter (#11) Now promise adapters comes out of the box: McGWeb\PromiseFactory\PromiseFactoryInterface is replaced by Overblog\PromiseAdapter\PromiseAdapterInterface, where the main difference between both interfaces are methods createResolve renamed to createFulfilled and createReject to createRejected
    Source code(tar.gz)
    Source code(zip)
  • v0.2.0(Nov 15, 2016)

  • v0.1.0(Nov 11, 2016)

Owner
Webedia - Overblog
Top European Blogging Platform
Webedia - Overblog
Caching implementation with a variety of storage options, as well as codified caching strategies for callbacks, classes, and output

laminas-cache Laminas\Cache provides a general cache system for PHP. The Laminas\Cache component is able to cache different patterns (class, object, o

Laminas Project 69 Jan 7, 2023
[READ-ONLY] Easy to use Caching library with support for multiple caching backends. This repo is a split of the main code that can be found in https://github.com/cakephp/cakephp

CakePHP Caching Library The Cache library provides a Cache service locator for interfacing with multiple caching backends using a simple to use interf

CakePHP 49 Sep 28, 2022
The next-generation caching layer for PHP

The next-generation caching layer for PHP

CacheWerk 115 Dec 25, 2022
Stash makes it easy to speed up your code by caching the results of expensive functions or code

Stash - A PHP Caching Library Stash makes it easy to speed up your code by caching the results of expensive functions or code. Certain actions, like d

Tedious Developments 943 Dec 15, 2022
A library providing platform-specific user directory paths, such as config and cache

Phirs A library providing platform-specific user directory paths, such as config and cache. Inspired by dirs-rs.

Mohammad Amin Chitgarha 7 Mar 1, 2022
Yii Caching Library - Redis Handler

Yii Caching Library - Redis Handler This package provides the Redis handler and implements PSR-16 cache. Requirements PHP 7.4 or higher. Installation

Yii Software 4 Oct 9, 2022
Query caching for Laravel

Query caching for Laravel

Dwight Watson 1k Dec 30, 2022
Simple Yet Powerful PHP Caching Class

The PHP high-performance object caching system ever. phpFastCache is a high-performance, distributed object caching system, generic in nature, but intended for use in speeding up dynamic web applications by alleviating database load. phpFastCache dropped the database load to almost nothing, yielding faster page load times for users, better resource utilization. It is simple yet powerful

Khoa Bui 28 Aug 19, 2022
Stash - A PHP Caching Library

Stash - A PHP Caching Library Stash makes it easy to speed up your code by caching the results of expensive functions or code. Certain actions, like d

Tedious Developments 943 Dec 15, 2022
Caching extension for the Intervention Image Class

Intervention Image Cache extends the Intervention Image Class package to be capable of image caching functionality.

null 616 Dec 30, 2022
Symfony Bundle for the Stash Caching Library

TedivmStashBundle The TedivmStashBundle integrates the Stash caching library into Symfony, providing a powerful abstraction for a range of caching eng

Tedious Developments 86 Aug 9, 2022
:zap: Simple Cache Abstraction Layer for PHP

⚡ Simple Cache Class This is a simple Cache Abstraction Layer for PHP >= 7.0 that provides a simple interaction with your cache-server. You can define

Lars Moelleken 27 Dec 8, 2022
Simple cache abstraction layer implementing PSR-16

sabre/cache This repository is a simple abstraction layer for key-value caches. It implements PSR-16. If you need a super-simple way to support PSR-16

sabre.io 48 Sep 9, 2022
PSR-15 middleware with various cache utilities

middlewares/cache Middleware components with the following cache utilities: CachePrevention Expires Cache Requirements PHP >= 7.2 A PSR-7 http library

Middlewares 15 Oct 25, 2022
A high-performance backend cache system. It is intended for use in speeding up dynamic web applications by alleviating database load.

A high-performance backend cache system. It is intended for use in speeding up dynamic web applications by alleviating database load. Well implemented, it can drops the database load to almost nothing, yielding faster page load times for users, better resource utilization. It is simple yet powerful.

PHPSocialNetwork 2.3k Dec 30, 2022
Refresh items in your cache without data races.

Cache Refresh Refresh items in your cache without data races. use Illuminate\Support\Facades\Cache; use Illuminate\Support\Collection; use App\Models\

Laragear 3 Jul 24, 2022
This plugin integrates cache functionality into Guzzle Bundle, a bundle for building RESTful web service clients.

Guzzle Bundle Cache Plugin This plugin integrates cache functionality into Guzzle Bundle, a bundle for building RESTful web service clients. Requireme

Vlad Gregurco 11 Sep 17, 2022
More Than Just a Cache: Redis Data Structures

More Than Just a Cache: Redis Data Structures Redis is a popular key-value store, commonly used as a cache or message broker service. However, it can

Andy Snell 2 Oct 16, 2021