Return results of findMany as map by id field value as key

[MurzNN]

At now the findMany() function returns the plain array of item objects, and there is not convenient to access individual items in it.

For example, I have users with ids = 123, 456, 789 and 100+ more items in result of findMany, and need to find the user with id = 456. I see only the way to iterate of all items via Array.find() function, that will eat too much resources for each search.

For solve this problem will be good to add option for return the map of item objects, with id (or, optionally, other required unique field value) as key. Other way is return the object by item id, but searching item in object is not very quick operation too, so map will be better.

What do you think about this idea?

[gautamsi]

You can always create reducer to map it as such. It needs be done either on server or on client. Database does not return result in the form other than array

[MurzNN]

I already do this now on many places, but, excluding the duplicated code, this is also the additional action, that costs many CPU cycles :) In this code of underlying function getItems()

keystone/packages/server-side-graphql-client/lib/server-side-graphql-client.js

Line 121 in 387e0cb

do {

we already have cycle per items, so make the ready-to-use Map in this place will be better for CPU load, i guess.
And results becomes more useful, because we will can quickly find needed item by id. This is like most of other frameworks (on PHP) works, with which I worked early, they returns the associative arrays, so in result of findMany I got the:

Map(2) {
  "123" => { id: "123", name: "Alice" },
  "456" => { id: "456", name: "Bob" }
}

instead of:

[
  { id: "123", name: "Alice" },
  { id: "456", name: "Bob" }
]

and can get the Bob from results quickly via users.get('456').

So glad to have same feature in Keystone without custom reducers.

[MurzNN]

I add same feature request directly to Prisma client prisma/prisma#6258 because this feature better to implement on adapter level, than on Keystone's side.

[bladey]

Thanks for the update @MurzNN.