PCE: Allow result extensions fields to depend on relational data

[millsp]

Extending a result with a computed field that needs data from a related model

I noticed that the when defining a result extension we are limited to scalar fields of the owning entity. We were really hoping to move an n+1 problem for computed fields into the prisma extension, but some of the needs data for the field comes from a relationship off the main entity. Here's an idea of what we're trying to do:

(Note: this code does not compile b/c quest is not a scalar field whereas questId is)

const xprisma = new PrismaClient().$extends({
  result: {
    questRun: {
      displayName: {
        // the dependencies
        needs: {
          status: true,
          name: true,
          startedAt: true,
          quest: {
            select: {
              showDateInRunName: true,
              timezone: true,
            },
          },
        },
        // the computation logic
        compute(questRun) {
          if (questRun.quest.showDateInRunName && questRun.startedAt) {
            const formattedDate = new Date(
              questRun.startedAt!
            ).toLocaleDateString(undefined, {
              weekday: "long",
              year: "numeric",
              month: "short",
              day: "numeric",
              timeZone: questRun.quest.timezone,
            });
            return `${questRun.name} - ${formattedDate}`;
          } else {
            return questRun.name;
          }
        },
      },
    },
  },
});

Why use the extension for this?

Some of the reasons we were looking at Prisma to do this is that we were hoping to have a way of querying the additional data in needs only when we are asking for displayName and also that that additional data would not be present on the resulting model object (unless it was also selected specifically when querying).

Why not roll our own?

We have many areas in our app where we want to retrieve multiple models with this computed displayName but are also sending the exact response given from Prisma back to the front-end. We were hoping to not have to add the needed fields in the initial query, add the computed field afterwards (and ensure typings), then somehow determine if we are supposed to remove or leave the needs fields depending on if they aren't intended to be there in the response or not.

TL;DR our alternatives require a relatively substantial increase in boilerplate that we otherwise haven't needed to date while introducing more opportunities for mistakes

Is our problem common?

Something could probably be said about simplifying our data structures to keep all the necessary data for our computed field within one table, but I think there will always be exceptions or good reasons for it to not be that way. Of course querying a relationship would have a performance impact, but we already have to suffer that performance impact when not using the prisma extension.

Is this by design?

Was it by design and strong intention to disallow using fields from related models in the needs of the computed field? Or was this chosen for technical/complexity-based reasons? Or some other reason I have not yet thought of?

Thanks for getting this far in my monologue and apologies if this has been answered before. I did skim over the comments in this thread, but didn't see this particular topic under discussion.

Cheers!
Jack (& The Questmate Team 🚀)

Originally posted by @Jackman3005 in #15074 (comment)

[millsp]

Closed as duplicate