0.14.1

Changelog

1. This release is compatible with the newest Prisma v2.22.
   The push operation now support multiple values, so the field update inputs has been changed accordingly:

   - @TypeGraphQL.Field(_type => String, {
   + @TypeGraphQL.Field(_type => [String], {
       nullable: true
     })
   - push?: string | undefined;
   + push?: string[] | undefined;

   However it should not produce breaking changes from the generated schema perspective due to a way how GraphQL handles lists in inputs.

2. Support for the orderByAggregateGroup preview release has been added 🚀
   Thanks to this, you can now sort the returned data by the results of aggregation, e.g.:

   query OrderByAggregateGroup {
     groupByPost(by: published, orderBy: { published: desc }) {
       published
       count {
         published
       }
     }
   }

   {
     "data": {
       "groupByPost": [
         {
           "published": true,
           "count": {
             "published": 3
           }
         },
         {
           "published": false,
           "count": {
             "published": 2
           }
         }
       ]
     }
   }

0.14.0

Changelog

1. Release 0.14.0 support new Prisma 2.21, which contains a breaking change - "aggregates are now nullable".
   So now all the fields of XYZSumAggregate and other similar classes are nullable, which may breaks your GraphQL clients, etc.

2. When you use the orderByRelation preview feature, the name of input types has been changed in DMMF from FooOrderByAggregateInput into FooOrderByRelationAggregateInput. This change is reflected in generated classes but shouldn't be a breaking change in the GraphQL schema from the clients perspective.

3. The behavior of output types nullability have been changed in order to match with the Prisma Client return types.
   Now all the optional fields have foo!: Foo | null required signature, so you can't just omit the fields when you construct the response manually - you need to explicitly provide null values to those fields.
   Also array fields are now non-nullable, just like they are in Prisma Client types.
   Be aware of that changes and upgrade your code if needed.

4. orderByAggregateGroup preview feature support is not ready yet - stay tuned for the next release 📻

0.13.1

Changelog

1. New release add support for the new Prisma preview feature selectRelationCount.
   This allows to get the number of related records with a simple GraphQL query, e.g.:

   query CountRelations {
     users {
       id
       email
       _count {
         posts
       }
     }
   }

2. v0.13.1 still works only with Prisma v2.20.1. Stay tuned for the new update, compatible with Prisma 2.21 🚀

0.13.0

Changelog

1. New release 0.13.0 now supports the latest Prisma v2.20, which fixes the issue with generator (#92).

2. New Prisma release moves groupBy and createMany features to general availability. This means you can expect new resolvers for queries and mutations (like CreateManyUserResolver), as well as new related args (like GroupByUserArgs) in the generated code or your schema.

3. Prisma v2.20 has added support for new push operation available for arrays on PostgreSQL.
   Thanks to this, you can easily add new items with a mutation, e.g.:

   mutation AddGrade {
     updateClient(where: { id: 1 }, data: { grades: { push: 5 } }) {
       ...ClientData
     }
   }

   {
    "data": {
      "updateClient": {
        "id": 1,
        "firstName": "John",
        "grades": [4, 5]
       }
     }
   }

4. selectRelationCount feature is not yet supported. Please wait for the next release 😉

0.12.0

Changelog

1. Supported Prisma version has been upgraded to 2.19 🎉
   This release allows to order by aggregates of relations, when you have set up previewFeatures = ["orderByRelation"], e.g.:

   query MostActiveUsers {
     users(take: 10, orderBy: [{ posts: { count: desc } }]) {
       firstName
       role
     }
   }

2. Since 0.10.2 it was possible to order by relation fields. However, in Prisma 2.19 this functionality is hidden behind the preview flag, so you need to set previewFeatures = ["orderByRelation"] in your schema.prisma file.
   Because of the Prisma 2.19 orderByRelation change, if you don't turn this flag on, some existing input like XYZOrderByInput type will be changed as they now do not contain the relation fields to sort by.

3. It is now possible to provide a special _all key in the EnhanceMap configs, which acts as a wildcard that allows to apply some decorators on all the fields of the selected type, e.g.:

   applyModelsEnhanceMap({
     Auth: {
       fields: {
         _all: [Authorized()],
       },
     },
   });

   It works with all the enhancers - applyModelsEnhanceMap, applyOutputTypesEnhanceMap, applyArgsTypesEnhanceMap, applyInputTypesEnhanceMap, applyRelationResolversEnhanceMap and applyResolversEnhanceMap 🚀

   This feature was a community idea (#45) so feel free to suggest some improvements too 😉

0.11.2

Changelog

1. The new release is compatible with the updated Prisma v2.18.0 🚀
   It doesn't contain any changes in DMMF or affect the generator flow in any way, so it's a simple version bump this time.

2. The last missing piece of applying custom decorators feature (#21) has been added 🎉
   You can now apply decorator to the relation fields of models, using applyRelationResolversEnhanceMap function:

   const clientRelationEnhanceConfig: RelationResolverActionsConfig<"Client"> = {
     posts: [
       UseMiddleware((_data, next) => {
         console.log("Client.posts relation field accessed");
         return next();
       }),
     ],
   };
   
   applyRelationResolversEnhanceMap({
     Client: clientRelationEnhanceConfig,
   });

0.11.1

Changelog

1. This release is focused on fixing some small issues only, no new features added this time:

   • fix imports in emitted *.js files - missing esModuleInterop: true when generating transpiled files (#60)
   • lower the size of generated code by moving transformFields function to helpers file
   • add checks for prisma provided in context (#46)

   You can expect some changes in the generated code but they shouldn't affect public API of the generated GraphQL resolver or types.

2. New features will be added next time - stay tuned! 🚀

0.11.0

Changelog

1. The new release is compatible with the updated Prisma v2.17.0 🚀 It contains a fix for an issue with CreateOrConnectWithout input types names, so expect a small change in the names of generated classes and files because of that:
   prisma/prisma#5302

2. Prisma 2.17 stabilized the "native types" feature, so do typegraphql-prisma supports it now 🎉

   It requires some changes in your codebase - mostly the graphql-type-json library has been replaced with graphql-scalars to support new BigInt and Decimal Prisma types properly. Please make sure to update your deps and expect a lot of changes in the generated files import statements because of that change.

   Thanks to the new native types feature, we can now both insert/update and fetch fields that are mapped to the native column types.
   So given that simple model:

   model NativeTypeModel {
     id      Int      @id @default(autoincrement()) @db.Integer
     bigInt  BigInt?  @db.BigInt
     byteA   Bytes?   @db.ByteA
     decimal Decimal? @db.Decimal
   }

   if we execute such query:

   mutation InsertNativeTypesFields {
     createNativeTypeModel(
       data: { bigInt: "987654321000000", decimal: "73.12", byteA: "BAgPEBcq" }
     ) {
       id
       bigInt
       byteA
       decimal
     }
   }

   we gonna receive the inserted data back properly:

   {
     "data": {
       "createNativeTypeModel": {
         "id": 5,
         "bigInt": "987654321000000",
         "byteA": {
           "type": "Buffer",
           "data": [
             4,
             8,
             15,
             16,
             23,
             42
           ]
         },
         "decimal": "73.12"
       }
     }
   }

   Be aware that both the Decimal and BigInt types are serialized and parsed as strings. Furthermore, the Buffer type returns a special structure as an output and accepts only hex and base64 strings as an input!

0.10.3

Changelog

1. The Prisma 2.16 preview feature createMany is now supported 🚀
   You can now execute batch insert mutations in a breeze:

   mutation CreateManyProblems {
     createManyProblem(
       data: [{ problemText: "problem1" }, { problemText: "problem2" }]
     ) {
       count
     }
   }

2. The v0.10.3 release now supports adding decorators to the input types and args type classes and their fields 🎉
   This feature might be very helpful if you want to e.g. add validation using class-validator library:

   import {
     applyInputTypesEnhanceMap,
     applyArgsTypesEnhanceMap,
   } from "./prisma/generated/type-graphql";
   
   applyArgsTypesEnhanceMap({
     CreateProblemArgs: {
       fields: {
         data: [ValidateNested()],
       },
     },
   });
   
   applyInputTypesEnhanceMap({
     ProblemCreateInput: {
       fields: {
         problemText: [MinLength(10)],
       },
     },
   });

   More info available in the docs:
   https://github.com/MichalLytek/typegraphql-prisma/blob/v0.10.3/Readme.md#additional-decorators-for-prisma-schema-classes-and-fields

0.10.2

Changelog

1. typegraphql-prisma now supports Prisma 2.16 release! 🚀 It introduced a lot of changes:

   • now all the list (array) properties, like model's one-to-many relations, are now emitted as non-nullable fields (#42)
   • BatchPayload output type was renamed by Prisma to AffectedRowsOutput
   • some input types were renamed by Prisma, like PostCreateManyWithoutAuthorInput -> PostCreateNestedManyWithoutAuthorInput, so be aware of the Nested change if you import/reference the types or generated input classes

2. The new Prisma preview feature orderByRelation is now supported. So you can now sort by relation fields like author: { role: asc } and that works in queries such as e.g.:

   query SortByRelation {
     posts(take: 5, orderBy: [{ author: { role: asc } }, { title: desc }]) {
       title
       author {
         firstName
         role
       }
     }
   }

3. The createMany operation support will come in the next release, stay tuned! 😉