Prisma•2w ago

Custom user type vs database type

I usually use the Prisma generated types throughout my app. But in my current project, I'm getting into problems. Example: Since it's a multi-tenant app, a user can belong to multiple organizations:

model User {
    id    String @id // Clerk ID
    email String

    organizationMemberships OrganizationMembership[]

    ,,,
}

model User {
    id    String @id // Clerk ID
    email String

    organizationMemberships OrganizationMembership[]

    ,,,
}

In my code, I only fetch the membership data for the currently active organization, which causes me to access the organization info like this:

<RoleBadge role={user.organizationMemberships[0].role} />

<RoleBadge role={user.organizationMemberships[0].role} />

This doesn't look great. Should I make my own user type and map the DB data to it? Then the user could have a role field.

4 Replies

Prisma AI Help•2w ago

You opted for speed from this bot. Let's conjure up an answer right now! Based on the information provided in the knowledge sources, I can offer some insights on how to handle your multi-tenant app scenario with Prisma. You're right that using user.organizationMemberships[0].role doesn't look ideal, especially if you're only dealing with the currently active organization. Creating a custom user type that maps the database data to a more convenient structure for your application logic is a good approach. Here are a couple of options you could consider: 1. Use Prisma Client Extensions: Prisma Client Extensions allow you to extend the functionality of your Prisma Client, including modifying the return types of queries. This could be useful for your multi-tenant scenario. Prisma Client Just Became a Lot More Flexible: Prisma Client Extensions (Preview) provides an example of using extensions for row-level security in a multi-tenant app, which might be adaptable to your needs. 2. Create a custom mapper: You could create a custom mapper function that transforms the Prisma-generated type into your desired structure. This approach is mentioned in a GitHub issue discussion about converting Prisma models to classes:

   const UserMapper = {
       fromPrisma(dbo: Partial<user> & {
           organization?: organization ; // facilitates the include clause
       }): UserModel {
           const entity = new UserModel();
           entity.id = dbo.id;
           entity.name = dbo.name;
           if (dbo.organization) entity.organization = OrganizationMapper.fromPrisma(dbo.organization);
           else if (dbo.organizationId) entity.organization = OrganizationMapper.fromPrisma({ id: dbo.organizationId });
           return entity;
       }
   };

   const UserMapper = {
       fromPrisma(dbo: Partial<user> & {
           organization?: organization ; // facilitates the include clause
       }): UserModel {
           const entity = new UserModel();
           entity.id = dbo.id;
           entity.name = dbo.name;
           if (dbo.organization) entity.organization = OrganizationMapper.fromPrisma(dbo.organization);
           else if (dbo.organizationId) entity.organization = OrganizationMapper.fromPrisma({ id: dbo.organizationId });
           return entity;
       }
   };

You could adapt this approach to include the role directly in your UserModel class. [Convert the Models from Types to Classes](https://github.com/prisma/pri sma/issues/5998) 3. Use Prisma's select or include options: When querying for a user, you could use Prisma's select or include options to shape the returned data more closely to what you need. For example:

   const user = await prisma.user.findUnique({
     where: { id: userId },
     include: {
       organizationMemberships: {
         where: { organizationId: activeOrgId },
         select: { role: true }
       }
     }
   });

   const user = await prisma.user.findUnique({
     where: { id: userId },
     include: {
       organizationMemberships: {
         where: { organizationId: activeOrgId },
         select: { role: true }
       }
     }
   });

This would give you a structure more like user.organizationMemberships[0].role, but it would only include the membership for the active organization. Remember, while these approaches can improve your code's readability and maintainability, they may have performance implications depending on your specific use case. Always profile and test to ensure your chosen solution meets your performance requirements. 🤔 Alright, thanks for letting us know that there's still some help needed. A team member will reply to you shortly. In the meantime, please let us know any additional info, questions, or which parts of the answer may need clarification.

Nurul•2w ago

Hey Florian 👋 It looks like you are looking for something like this: https://www.prisma.io/docs/orm/prisma-client/type-safety/operating-against-partial-structures-of-model-types#problem-using-variations-of-the-generated-model-type

Operating against partial structures of your model types | Prisma D...

This page documents various scenarios for using the generated types from the Prisma namespace

FlorianOP•2w ago

That just gives me what I already have—a User type with an organizations array. I'm wondering about best practices when the User I need in my app doesn't fit the Prisma type anymore.

Nurul•7d ago

In that case you would need to create a custom type

Gaming

Programming

Custom user type vs database type

Did you find this page helpful?