Merge branch 'master' into bugfix/mongoose-query-service-accept-any-ids

Author: simnado

CHANGELOG.md

@@ -880,7 +880,7 @@
 
 ### Bug Fixes
 
-* **typeorm, #954:** Filtering on relations with pagination  ([#977](https://github.com/tripss/nestjs-query/issues/977)) ([f5a6374](https://github.com/tripss/nestjs-query/commit/f5a6374f6e22470f63ef6257f7271c818ed09321)), closes [#954](https://github.com/tripss/nestjs-query/issues/954) [#954](https://github.com/tripss/nestjs-query/issues/954) [#954](https://github.com/tripss/nestjs-query/issues/954) [#954](https://github.com/tripss/nestjs-query/issues/954)
+* **typeorm, #954:** Filtering on relations with pagination  ([#977](https://github.com/tripss/nestjs-query/issues/977)) ([f5a6374](https://github.com/tripss/nestjs-query/commit/f5a6374f6e22470f63ef6257f7271c818ed09321)), closes [#954](https://github.com/doug-martin/nestjs-query/issues/954) [#954](https://github.com/doug-martin/nestjs-query/issues/954) [#954](https://github.com/doug-martin/nestjs-query/issues/954) [#954](https://github.com/doug-martin/nestjs-query/issues/954)
 
 
 

documentation/docs/concepts/queries.mdx

@@ -170,15 +170,6 @@ const q: Query<MyClass> = {
 </TabItem>
 </Tabs>
 
-:::note
-When using filters on relations with `typeorm` in combination with paging, performance can be degraded on large result
-sets. For more info see this [issue](https://github.com/tripss/nestjs-query/issues/954)
-
-In short two queries will be executed:
-* The first one fetching a distinct list of primary keys with paging applied.
-* The second uses primary keys from the first query to fetch the actual records.
-:::
-
 ---
 
 ## Sorting

documentation/docs/graphql/dataloaders.mdx

@@ -3,9 +3,9 @@ title: Dataloaders
 sidebar_label: Dataloaders
 ---
 
-Nestjs-query integrates a standard implementation of [dataloaders](https://www.npmjs.com/package/dataloader/v/2.1.0). Dataloaders are there to solve the `n+1`. Sometimes the default implementation can fail, for example when asynchronous [custom authorizers](./authorization.mdx#custom-authorizer) are used and the `n+1` problem occurs again despite using dataloaders. Then it may be useful to configure the default implementation of the dataloader, for example to pass a custom batch scheduler.
+Nestjs-query integrates a standard implementation of [dataloaders](https://www.npmjs.com/package/dataloader/v/2.2.2). Dataloaders are there to solve the `n+1`. Sometimes the default implementation can fail, for example when asynchronous [custom authorizers](./authorization.mdx#custom-authorizer) are used and the `n+1` problem occurs again despite using dataloaders. Then it may be useful to configure the default implementation of the dataloader, for example to pass a custom batch scheduler.
 
-The following example demonstrates how to configure the generated dataloaders. For more information about the dataloader configuration, see the [dataloader documentation](https://www.npmjs.com/package/dataloader/v/2.1.0).
+The following example demonstrates how to configure the generated dataloaders. For more information about the dataloader configuration, see the [dataloader documentation](https://www.npmjs.com/package/dataloader/v/2.2.2).
 
 ```ts title="app.module.ts"
 import { Module } from '@nestjs/common';

documentation/docs/graphql/dtos.mdx

@@ -5,7 +5,7 @@ title: DTOs
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-The `query-graphql` package leverages most decorators from [`@nestjs/graphql`](https://docs.nestjs.com/graphql/quick-start) and [TypeGraphQL](https://typegraphql.ml), with the exception of `FilterableField`.
+The `query-graphql` package leverages most decorators from [`@nestjs/graphql`](https://docs.nestjs.com/graphql/quick-start) and [TypeGraphQL](https://typegraphql.com), with the exception of `FilterableField`.
 
 ## `@FilterableField`
 
@@ -148,8 +148,7 @@ export class TodoItemDTO {
 
 ## `@IDField`
 
-By default `nestjs-query` uses the default graphql `ID` scalar, if you need to use a different `graphql` `scalar`
-type you can  `@IDField` decorator. `nestjs-query` will `scalar` type passed to the `@IDField` for all auto-generated
+By default `nestjs-query` uses the default graphql `ID` scalar, if you need to use a different `graphql` `scalar` type you can use `@IDField` decorator. `nestjs-query` will use that `scalar` type passed to the `@IDField` for all auto-generated
 `query` and `mutation` endpoints that rely on an input for the `id` (e.g. `findById`, `updateOne`, `deleteOne`).
 
 :::note
@@ -426,7 +425,7 @@ You can override the default `pagingStrategy` to one of the following alternativ
 * `OFFSET` - sets paging to allow `limit` and `offset` fields, and returns an `OffsetConnection`.
 * `NONE` - turn off all paging and always return an `ArrayConnection`.
 
-When using the `OFFSET` strategy your the paging arguments for a many query will accept a `limit` and/or `offset`.
+When using the `OFFSET` strategy your paging arguments for a many query will accept a `limit` and/or `offset`.
 This will also change the return type from a `CursorConnection` to an `OffsetConnection`.
 
 ```ts title="todo-item.dto.ts" {5}

documentation/docs/graphql/queries/endpoints.mdx

@@ -99,7 +99,7 @@ All examples below assume that a connection is returned but filtering and sortin
 strategies. To read how to page collections read the [paging docs](./paging)
 :::
 
-By default if you do not provided an arguments you can query for all records.
+By default if you do not provided an arguments it will uses a default value for [the page size](../dtos#result-page-size) and for the [sorting](../dtos/#default-sort).
 
 <Tabs
   defaultValue="graphql"

documentation/docs/graphql/queries/filtering.mdx

@@ -5,7 +5,7 @@ title: Filtering
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-Filtering in `query-graphql` has has an object based syntax
+Filtering in `nestjs-query` has an object based syntax.
 
 For a full reference of filter operations [see filter reference](../../concepts/queries.mdx#filter-reference)
 
@@ -88,20 +88,20 @@ The following example filters for all todoItems that are marked completed.
 
 ## Setting the generated filter-type depth
 
-When querying the default filter is one level deep. You can specify the generated filter-type depth by using the QueryOptions decorator on your DTO.
+When querying the default filter is one level deep. You can specify the generated filter-type depth by using the `QueryOptions` decorator on your DTO.
 
-You can find the documentation and an example in the [QueryOptions reference](../dtos.mdx#generated-filter-type-depth).
+You can find the documentation and an example in the [`QueryOptions` reference](../dtos.mdx#generated-filter-type-depth).
 
 
 ## Setting a default filter
 
-When querying the default filter is empty. You can specify a default filter by using the QueryOptions decorator on your DTO.
+When querying the default filter is empty. You can specify a default filter by using the `QueryOptions` decorator on your DTO.
 
-You can find the documentation and an example in the [QueryOptions reference](../dtos.mdx#setting-a-default-filter).
+You can find the documentation and an example in the [`QueryOptions` reference](../dtos.mdx#setting-a-default-filter).
 
 
 ## Setting allowed boolean expressions
 
-When filtering you can provide and and or expressions to provide advanced filtering. You can turn off either by using the QueryOptions decorator on your DTO.
+When filtering you can provide `and` and `or` expressions to provide advanced filtering. You can turn off either by using the `QueryOptions` decorator on your DTO.
 
-You can find the documentation and an example in the [QueryOptions reference](../dtos.mdx#allowed-boolean-expressions).
+You can find the documentation and an example in the [`QueryOptions` reference](../dtos.mdx#allowed-boolean-expressions).

documentation/docs/graphql/resolvers.mdx

@@ -714,7 +714,7 @@ export class TodoItemResolver extends CRUDResolver(TodoItemDTO, {
 If you find yourself in a situation where you want to override an endpoint name you can use the `one.name` or `many.name` options to override
 
 :::note
-These options are available for the `create`, `read`, `update`, and 'delete' endpoints.
+These options are available for the `create`, `read`, `update`, and `delete` endpoints.
 :::
 
 In this example we'll change the `todoItem` query to `findTodoItem` and the `todoItems` endpoint to `queryForTodoItems`.
@@ -967,7 +967,7 @@ completedTodoItems(
   sorting: [TodoItemSort!] = []
 ): TodoItemConnection!
 ```
-Notice how there is not a query arg but instead the you see the fields of `TodoItemQuery` that is because we used
+Notice how there is not a `query` arg but instead you see the fields of `TodoItemQuery`, that is because we used
 `@Args` without a name and added the `@ArgsType` decorator to the `TodoItemQuery`.
 
 The next piece is
@@ -983,7 +983,7 @@ const filter: Filter<TodoItemDTO> = {
 Here we do a shallow copy of the `filter` and add `completed: { is: true }`. This will override any completed arguments
 that an end user may have provided to ensure we always query for completed todos.
 
-Finally we call create our connection response by using the `createFromPromise` method on the connection.
+Finally we create our connection response by using the `createFromPromise` method on the connection.
 
 ```ts
 // call the original queryMany method with the new query

documentation/docs/persistence/services.mdx

@@ -4,7 +4,7 @@ title: Services
 import Tabs from '@theme/Tabs';
 import TabItem from '@theme/TabItem';
 
-`@nestjs-query` provides a common interface to use difference ORMs inorder to query and mutate your data.
+`@nestjs-query` provides a common interface to use different ORMs in order to query and mutate your data.
 
 The following ORMs are supported out of the box.
 
@@ -170,7 +170,7 @@ export class TodoItemEntity implements Base {
 
 ### Module
 
-The `nestjs-query` `typeorm`, `sequelize`, `mongoose`, and 'typegoose' packages provide a module that will add providers
+The `nestjs-query` `typeorm`, `sequelize`, `mongoose`, and `typegoose` packages provide a module that will add providers
  to inject auto-created `QueryServices` using the `@InjectQueryService` decorator.
 
 In order to use the decorator you will need to use the module that comes with the `nestjs-query` orm module providing it your entities that you want the services created for.
@@ -378,7 +378,7 @@ try {
 
 To perform an `aggregate` query you can use the `aggregate` method which accepts a `Filter` and `AggregateQuery`.
 
-Supported aggregates are `count`, 'sum', 'avg', `min` and `max`.
+Supported aggregates are `count`, `sum`, `avg`, `min` and `max`.
 
 In this example we'll aggregate on all records.
 
@@ -672,7 +672,7 @@ This section only applies when you combine your DTO and entity and are using Typ
 
 When your DTO and entity are the same class and you have relations defined, you should not decorate your the relations in the DTO with `@Field` or `@FilterableField`.
 
-Instead decorate the class with `@CursorConnection`, `@OffsetConnection`, '@UnPagedRelation' or `@Relation`.
+Instead decorate the class with `@CursorConnection`, `@OffsetConnection`, `@UnPagedRelation` or `@Relation`.
 
 ### Example
 

examples/all-paging/e2e/fixtures.ts

@@ -1,19 +1,19 @@
-import { Connection } from 'typeorm'
+import { DataSource } from 'typeorm'
 
 import { executeTruncate } from '../../helpers'
 import { SubTaskEntity } from '../src/sub-task/sub-task.entity'
 import { TagEntity } from '../src/tag/tag.entity'
 import { TodoItemEntity } from '../src/todo-item/todo-item.entity'
 
 const tables = ['todo_item', 'sub_task', 'tag']
-export const truncate = async (connection: Connection): Promise<void> => executeTruncate(connection, tables)
+export const truncate = async (dataSource: DataSource): Promise<void> => executeTruncate(dataSource, tables)
 
-export const refresh = async (connection: Connection): Promise<void> => {
-  await truncate(connection)
+export const refresh = async (dataSource: DataSource): Promise<void> => {
+  await truncate(dataSource)
 
-  const todoRepo = connection.getRepository(TodoItemEntity)
-  const subTaskRepo = connection.getRepository(SubTaskEntity)
-  const tagsRepo = connection.getRepository(TagEntity)
+  const todoRepo = dataSource.getRepository(TodoItemEntity)
+  const subTaskRepo = dataSource.getRepository(SubTaskEntity)
+  const tagsRepo = dataSource.getRepository(TagEntity)
 
   const urgentTag = await tagsRepo.save({ name: 'Urgent' })
   const homeTag = await tagsRepo.save({ name: 'Home' })

examples/all-paging/e2e/sub-task.resolver.spec.ts

@@ -2,7 +2,7 @@ import { INestApplication, ValidationPipe } from '@nestjs/common'
 import { Test } from '@nestjs/testing'
 import { CursorConnectionType } from '@ptc-org/nestjs-query-graphql'
 import request from 'supertest'
-import { Connection } from 'typeorm'
+import { DataSource } from 'typeorm'
 
 import { AppModule } from '../src/app.module'
 import { SubTaskDTO } from '../src/sub-task/dto/sub-task.dto'
@@ -29,10 +29,10 @@ describe('SubTaskResolver (limitOffset - e2e)', () => {
     )
 
     await app.init()
-    await refresh(app.get(Connection))
+    await refresh(app.get(DataSource))
   })
 
-  afterAll(() => refresh(app.get(Connection)))
+  afterAll(() => refresh(app.get(DataSource)))
 
   const subTasks = [
     { id: '1', title: 'Create Nest App - Sub Task 1', completed: true, description: null, todoItemId: '1' },