Select fields and pagination aliases

[PatrickMunsey]

Hi,

This looks like a great library. I've been experimenting with it and I'm wondering if there are any plans on adding a select field feature and eventaually something to accomodate cursor pagination. I'm looking at exploring this myself and was wondering if you could give me some guidance as I continue to wrap my head around things.

Some notes:

• I'm already able to add a field to the DTO called select of type string[] which generates an array of all field names passed through the query string
• The field names in select: string[] that are also within the keys array should be added to a select query field in findOptions
• Field names specified within the select query field that are also within the compound keys array should added to an include query field in findOptions
• Generated prisma select and include statements returned from findOptions are optional and can be equal to null but must not be not-null at the same time
• I've noted that <prismamodel>WhereInput type is used to initialise the DirectFilterPipe instead of something like <prismamodel>FindManyArgs which is making it hard for me to figure out how to add select and include fields with non-null type to generateQueryFindOptions and GeneratedFindOptions.
• I've tried adding and/or subsbtituting the <prismamodel>FindManyArgs type into the IGeneratedFilter interface and dependant types to get these extra select, include and cursor types from prisma to play with but with no success so far.
• Using the <prismamodel>FindManyArgs type may also make it easier to add cursor handling functionality in the future?

If I can figure it out in the meantime I'll make a pull request if you like. I'm also happy to pair with someone on your team if that appeals to you.

Thanks

[Valerionn]

Hey,

I'm happy to hear that you like this library. It has currently all features we need internally - but I'm happy to help to make it better if I have time :)

General response:

• I think it would help if you could explain why you would need a dynamic select so I can understand your use-case to find a good implementation for this. I would guess some kind of dynamic data query similar to GraphQL in which the client specifies what fields can be selected? Maybe you have some example code for me how you would want the library to behave in a specific scenario?
• Currently, the library doesn't generate include/select because it assumes that you will specify it manually (because, if you want to process the query result, then you have to know what is included in the result which is not really possible if it's dynamic. That's why I'm asking for the specific use-case).
• Cursor based pagination should be pretty easy to implement. However, we would have to think about where to specify the cursor field name (e.g. "id") - is it something that is specified when creating a DirectFilterPipe (only one cursor type allowed) or something that the client hast to send as well? That's especially important, because you always have to sort by the cursor field (otherwise the results are unpredictable)

Trying to answer your questions specifically:

I've tried adding and/or subsbtituting the FindManyArgs type into the IGeneratedFilter interface and dependant types to get these extra select, include and cursor types from prisma to play with but with no success so far.

If you want to insert FindManyArgs instead of WhereInput, then something like this should be possible (untested, just an idea):

export type GeneratedFindOptions<TFindManyArgs extends { where: unknown; select: unknown; }> = {
  where: TFindManyArgs['where'];
  select: TFindManyArgs['select'];
  skip: number | undefined;
  take: number | undefined;
  // This can be "any" because we might order by relations, therefore this will be an object
  orderBy: Array<{ [p in keyof TWhereInput]?: FilterOrder | any }>;
};

and then you should be able to use it. In the future, we could maybe improve this, but it should work for now.

I would have to check all the usages in our current projects to see if changing it to <prismamodel>FindManyArgs would be possible everywhere (for version 3), but if there are no conflicts there, then I don't see a problem with changing it.

Field names specified within the select query field that are also within the compound keys array should added to an include query field in findOptions

Why do you want to add it to include in this case and not select as well?

---

If you have any other specific questions, then feel free to ask them and I'll try my best to answer them. I'll try to look into these topics (especially cursor paged pagination) myself aswell - but this might take some time.

[PatrickMunsey]

Hi,

I've just put together some changes that should add some of the above discussed functionality. I've submitted a pull request so you can see the changes and we can have a more in depth discussion.

Some further thoughts specifically to the points above:

• I've got a function of select working where field names are simply added to a query string such as select=firstName,lastName,roles.id. This support both record fields and related record fields. This achieved what you suggested as some kind of dynamic data query similar to GraphQL in which the client specifies what fields can be selected.
• I've added functionality to handle default includes (optionally specified at pipe creation) and logic to handle the conflicts between select and includes being speicified. All of this has simplified our nestjs services and controllers so a lot of repeated prisma query generation boiler plate can be defaulted (optionaly) . I've also been adding a metadata object to the api responses with the query to help with client side dynamic data shapes beyond openapi exported dto types.

I'll look into the curser pagination points tomorrow and let you know my thoughts

[darr1s]

Hi @Valerionn @PatrickMunsey any updates on merging this to main?