Loading by an alternative key about dataloader HOT 5 CLOSED

The cache here is extremely simple, it's really just memoization. I think adding secondary key to the cache would be pretty complicating.

At Facebook we actually have a two-phase load. vanity => userid first then userid => user object. There's two ways I can think of to do this:

// follow-up in user code

var vanityLoader = new DataLoader(
  vanities => promiseVanityToUserIDs(vanities)
)

var userLoader = new DataLoader(
  ids => promiseUsersByID(ids)
)

var ide = await vanityLoader.load('ide').then(id => userLoader.load(id));

// or follow-up in loader code

var userLoader = new DataLoader(
  ids => promiseUsersByID(ids)
)

var vanityLoader = new DataLoader(
  vanities => promiseVanityToUserIDs(vanities).then(
    ids => userLoader.loadMany(ids)
  )
)

var ide = await vanityLoader.load('ide');

from dataloader.

I wonder what the simplest possible approach would be to supporting a two-way cache? Maybe a cache population method? Or just providing a custom cache backend?

What if you could write: loader.prime(key, value)

var userLoader = new DataLoader(
  ids => promiseUsersByID(ids).then(users => {
    users.forEach(user => vanityLoader.prime(user.vanity, user));
    return users;
  })
)

var vanityLoader = new DataLoader(
  vanities => promiseUsersByVanity(vanities).then(users => {
    users.forEach(user => userLoader.prime(user.id, user));
    return users;
  })
)

// Possible race condition? What should happen?

var [ ide1, ide2 ] = await Promise.all(
  vanityLoader.load('ide'),
  userLoader.load(589436611)
)
console.log(ide1 === ide2)

from dataloader.

@leebyron thanks - I wrote up something like the example in your first comment last night and it's working fine. In my case it felt a little silly to have the second loader because the second key (e.g. vanity) was on the user object so I was reading from the same table in both loaders instead of doing just one query.

loader.prime is an interesting idea. To address the race condition I think the DataLoader options would need to include some kind of conflict-resolution policy: first write wins, last write wins, db always wins over prime, or an arbitrary function.

The thing I like about the custom cache backend is that you can add LRU policies and other behavior. One idea I was toying with is to keep per-user DataLoaders across requests for a few minutes so being able to control memory usage is important (this idea only works if you have a small number of servers or session stickiness though).

Still leaning towards loader.prime since it's simple and can be called from anywhere but probably need to understand more use cases.

from dataloader.

The thing I like about the custom cache backend is that you can add LRU policies and other behavior.

Most definitely. This occurred to me recently as well. A memoization cache is only acceptable for short-lived caches. You would definitely need something like an LRU cache if you wanted a longer-lived loader.

from dataloader.

This is now possible in v1.2.0.

The race condition discussed here is more trivially and acceptably handled by making it a race between the synchronous calls to load and prime rather than making calling prime race with the async return of load.

from dataloader.