Remove findByIds method from MongoRepository

src/repository/MongoRepository.ts

Remove findByIds static method from BaseEntity

src/repository/BaseEntity.ts

Refactor MongoDB path to use createEntityCursor

src/persistence/SubjectDatabaseEntityLoader.ts

Refactor to use createQueryBuilder with whereInIds

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts

Remove test for findByIds with ObjectId and strings

test/functional/mongodb/basic/mongo-repository/mongo-repository.test.ts

Remove test assertions for findByIds method

test/functional/mongodb/basic/repository-actions/mongodb-repository-actions.test.ts

Remove findByIds test suite

test/functional/repository/find-methods/repostiory-find-methods.test.ts

Remove test file for findByIds empty array handling

test/github-issues/1118/issue-1118.test.ts

Remove Post entity file for issue 1118

test/github-issues/1118/entity/Post.ts

Update test title to reflect actual method tested

test/github-issues/1233/issue-1233.test.ts

Update test titles from findByIds to findBy with In

test/github-issues/1245/issue-1245.test.ts

Update test titles to reflect actual methods tested

test/github-issues/1929/issue-1929.test.ts

Add migration guide for findByIds removal

docs/docs/guides/8-migration-v1.md

Description

The migration guide states findByIds was removed from MongoEntityManager, but the PR
reintroduces a public MongoEntityManager.findByIds() method. This makes the docs inaccurate for
users relying on the stated public API changes.

Code

src/entity-manager/MongoEntityManager.ts[R961-993]

+    /**
+     * Finds entities by an array of ids, resolving ObjectId types as needed.
+     * @param entityClassOrName
+     * @param ids
+     */
+    async findByIds<Entity extends ObjectLiteral>(
+        entityClassOrName: EntityTarget<Entity>,
+        ids: any[],
+    ): Promise<Entity[]> {
+        const metadata = this.connection.getMetadata(entityClassOrName)
+        const objectIdInstance = PlatformTools.load("mongodb").ObjectId
+        const cursor = this.createEntityCursor<Entity>(entityClassOrName, {
+            _id: {
+                $in: ids.map((id) => {
+                    if (typeof id === "string") {
+                        return new objectIdInstance(id)
+                    }
+                    if (typeof id === "object") {
+                        if (id instanceof objectIdInstance) {
+                            return id
+                        }
+                        const propertyName =
+                            metadata.objectIdColumn!.propertyName
+                        if (id[propertyName] instanceof objectIdInstance) {
+                            return id[propertyName]
+                        }
+                    }
+                    return id
+                }),
+            },
+        } as Filter<Entity>)
+        return cursor.toArray()
+    }

Evidence

Compliance requires docs to accurately reflect user-facing API changes; the migration guide claims
findByIds was removed from MongoEntityManager, but the PR adds async findByIds(...) without
protected/private, meaning it remains publicly accessible.

Rule 2: Docs updated for user-facing changes
docs/docs/guides/8-migration-v1.md[232-235]
src/entity-manager/MongoEntityManager.ts[961-993]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide says `findByIds` was removed from `MongoEntityManager`, but the PR adds `MongoEntityManager.findByIds()` as a public method (no `protected`/`private`). This makes the docs inaccurate and keeps a deprecated-looking API surface.
## Issue Context
The migration guide explicitly lists `MongoEntityManager` among the APIs where `findByIds` was removed. Internal code paths in this PR call `mongoManager.findByIds(...)`, which also implies the API still exists.
## Fix Focus Areas
- src/entity-manager/MongoEntityManager.ts[961-993]
- src/persistence/SubjectDatabaseEntityLoader.ts[114-119]
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[132-153]
- docs/docs/guides/8-migration-v1.md[232-235]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide says findByIds removal applies to MongoDB APIs and recommends `findBy({ id:
In([...]) })`, but Mongo find paths pass the filter directly to MongoDB with no translation of
TypeORM FindOperator (like In) and Mongo id filtering uses _id (not id). Mongo users
following the guide will likely get empty results or incorrect queries.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly includes MongoDB managers/repositories yet shows the SQL-style In()
replacement. In MongoDB, findBy/find ultimately call collection.find(filter) with the provided
where/filter object; there is no code in the Mongo path that recognizes/rewrites TypeORM
FindOperator (produced by In()) into Mongo $in. Existing Mongo tests also demonstrate querying
ObjectId columns via _id, not id.

docs/docs/guides/8-migration-v1.md[232-244]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1235]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/find-options/operator/In.ts[8-12]
src/find-options/FindOperator.ts[12-67]
test/functional/mongodb/basic/object-id/mongodb-object-id.test.ts[69-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide currently states that `findByIds` was removed from MongoDB APIs too, but it recommends the relational replacement (`findBy` + `In`) which is not translated in the MongoDB codepath.
### Issue Context
MongoDB find methods pass the filter object directly into `collection.find(...)` without converting TypeORM `FindOperator` instances (like `In`) into Mongo operators (like `$in`). Mongo tests also show querying ObjectId columns via `_id`.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]
### Suggested change
Adjust the section to:
1) Clearly label the existing snippet as **SQL/relational**.
2) Add a **MongoDB** snippet, e.g.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
             )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
            )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
               )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
              )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide states findByIds was removed from MongoEntityManager, but the PR
reintroduces a public MongoEntityManager.findByIds() method. This makes the docs inaccurate for
users relying on the stated public API changes.

Code

src/entity-manager/MongoEntityManager.ts[R961-993]

+    /**
+     * Finds entities by an array of ids, resolving ObjectId types as needed.
+     * @param entityClassOrName
+     * @param ids
+     */
+    async findByIds<Entity extends ObjectLiteral>(
+        entityClassOrName: EntityTarget<Entity>,
+        ids: any[],
+    ): Promise<Entity[]> {
+        const metadata = this.connection.getMetadata(entityClassOrName)
+        const objectIdInstance = PlatformTools.load("mongodb").ObjectId
+        const cursor = this.createEntityCursor<Entity>(entityClassOrName, {
+            _id: {
+                $in: ids.map((id) => {
+                    if (typeof id === "string") {
+                        return new objectIdInstance(id)
+                    }
+                    if (typeof id === "object") {
+                        if (id instanceof objectIdInstance) {
+                            return id
+                        }
+                        const propertyName =
+                            metadata.objectIdColumn!.propertyName
+                        if (id[propertyName] instanceof objectIdInstance) {
+                            return id[propertyName]
+                        }
+                    }
+                    return id
+                }),
+            },
+        } as Filter<Entity>)
+        return cursor.toArray()
+    }

Evidence

Compliance requires docs to accurately reflect user-facing API changes; the migration guide claims
findByIds was removed from MongoEntityManager, but the PR adds async findByIds(...) without
protected/private, meaning it remains publicly accessible.

Rule 2: Docs updated for user-facing changes
docs/docs/guides/8-migration-v1.md[232-235]
src/entity-manager/MongoEntityManager.ts[961-993]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide says `findByIds` was removed from `MongoEntityManager`, but the PR adds `MongoEntityManager.findByIds()` as a public method (no `protected`/`private`). This makes the docs inaccurate and keeps a deprecated-looking API surface.
## Issue Context
The migration guide explicitly lists `MongoEntityManager` among the APIs where `findByIds` was removed. Internal code paths in this PR call `mongoManager.findByIds(...)`, which also implies the API still exists.
## Fix Focus Areas
- src/entity-manager/MongoEntityManager.ts[961-993]
- src/persistence/SubjectDatabaseEntityLoader.ts[114-119]
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[132-153]
- docs/docs/guides/8-migration-v1.md[232-235]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide says findByIds removal applies to MongoDB APIs and recommends `findBy({ id:
In([...]) })`, but Mongo find paths pass the filter directly to MongoDB with no translation of
TypeORM FindOperator (like In) and Mongo id filtering uses _id (not id). Mongo users
following the guide will likely get empty results or incorrect queries.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly includes MongoDB managers/repositories yet shows the SQL-style In()
replacement. In MongoDB, findBy/find ultimately call collection.find(filter) with the provided
where/filter object; there is no code in the Mongo path that recognizes/rewrites TypeORM
FindOperator (produced by In()) into Mongo $in. Existing Mongo tests also demonstrate querying
ObjectId columns via _id, not id.

docs/docs/guides/8-migration-v1.md[232-244]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1235]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/find-options/operator/In.ts[8-12]
src/find-options/FindOperator.ts[12-67]
test/functional/mongodb/basic/object-id/mongodb-object-id.test.ts[69-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide currently states that `findByIds` was removed from MongoDB APIs too, but it recommends the relational replacement (`findBy` + `In`) which is not translated in the MongoDB codepath.
### Issue Context
MongoDB find methods pass the filter object directly into `collection.find(...)` without converting TypeORM `FindOperator` instances (like `In`) into Mongo operators (like `$in`). Mongo tests also show querying ObjectId columns via `_id`.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]
### Suggested change
Adjust the section to:
1) Clearly label the existing snippet as **SQL/relational**.
2) Add a **MongoDB** snippet, e.g.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
              )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
             )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide says findByIds removal applies to MongoDB APIs and recommends `findBy({ id:
In([...]) })`, but Mongo find paths pass the filter directly to MongoDB with no translation of
TypeORM FindOperator (like In) and Mongo id filtering uses _id (not id). Mongo users
following the guide will likely get empty results or incorrect queries.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly includes MongoDB managers/repositories yet shows the SQL-style In()
replacement. In MongoDB, findBy/find ultimately call collection.find(filter) with the provided
where/filter object; there is no code in the Mongo path that recognizes/rewrites TypeORM
FindOperator (produced by In()) into Mongo $in. Existing Mongo tests also demonstrate querying
ObjectId columns via _id, not id.

docs/docs/guides/8-migration-v1.md[232-244]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1235]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/find-options/operator/In.ts[8-12]
src/find-options/FindOperator.ts[12-67]
test/functional/mongodb/basic/object-id/mongodb-object-id.test.ts[69-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide currently states that `findByIds` was removed from MongoDB APIs too, but it recommends the relational replacement (`findBy` + `In`) which is not translated in the MongoDB codepath.
### Issue Context
MongoDB find methods pass the filter object directly into `collection.find(...)` without converting TypeORM `FindOperator` instances (like `In`) into Mongo operators (like `$in`). Mongo tests also show querying ObjectId columns via `_id`.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]
### Suggested change
Adjust the section to:
1) Clearly label the existing snippet as **SQL/relational**.
2) Add a **MongoDB** snippet, e.g.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
             )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
            )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide states findByIds was removed from MongoEntityManager, but the PR
reintroduces a public MongoEntityManager.findByIds() method. This makes the docs inaccurate for
users relying on the stated public API changes.

Code

src/entity-manager/MongoEntityManager.ts[R961-993]

+    /**
+     * Finds entities by an array of ids, resolving ObjectId types as needed.
+     * @param entityClassOrName
+     * @param ids
+     */
+    async findByIds<Entity extends ObjectLiteral>(
+        entityClassOrName: EntityTarget<Entity>,
+        ids: any[],
+    ): Promise<Entity[]> {
+        const metadata = this.connection.getMetadata(entityClassOrName)
+        const objectIdInstance = PlatformTools.load("mongodb").ObjectId
+        const cursor = this.createEntityCursor<Entity>(entityClassOrName, {
+            _id: {
+                $in: ids.map((id) => {
+                    if (typeof id === "string") {
+                        return new objectIdInstance(id)
+                    }
+                    if (typeof id === "object") {
+                        if (id instanceof objectIdInstance) {
+                            return id
+                        }
+                        const propertyName =
+                            metadata.objectIdColumn!.propertyName
+                        if (id[propertyName] instanceof objectIdInstance) {
+                            return id[propertyName]
+                        }
+                    }
+                    return id
+                }),
+            },
+        } as Filter<Entity>)
+        return cursor.toArray()
+    }

Evidence

Compliance requires docs to accurately reflect user-facing API changes; the migration guide claims
findByIds was removed from MongoEntityManager, but the PR adds async findByIds(...) without
protected/private, meaning it remains publicly accessible.

Rule 2: Docs updated for user-facing changes
docs/docs/guides/8-migration-v1.md[232-235]
src/entity-manager/MongoEntityManager.ts[961-993]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide says `findByIds` was removed from `MongoEntityManager`, but the PR adds `MongoEntityManager.findByIds()` as a public method (no `protected`/`private`). This makes the docs inaccurate and keeps a deprecated-looking API surface.
## Issue Context
The migration guide explicitly lists `MongoEntityManager` among the APIs where `findByIds` was removed. Internal code paths in this PR call `mongoManager.findByIds(...)`, which also implies the API still exists.
## Fix Focus Areas
- src/entity-manager/MongoEntityManager.ts[961-993]
- src/persistence/SubjectDatabaseEntityLoader.ts[114-119]
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[132-153]
- docs/docs/guides/8-migration-v1.md[232-235]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide says findByIds removal applies to MongoDB APIs and recommends `findBy({ id:
In([...]) })`, but Mongo find paths pass the filter directly to MongoDB with no translation of
TypeORM FindOperator (like In) and Mongo id filtering uses _id (not id). Mongo users
following the guide will likely get empty results or incorrect queries.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly includes MongoDB managers/repositories yet shows the SQL-style In()
replacement. In MongoDB, findBy/find ultimately call collection.find(filter) with the provided
where/filter object; there is no code in the Mongo path that recognizes/rewrites TypeORM
FindOperator (produced by In()) into Mongo $in. Existing Mongo tests also demonstrate querying
ObjectId columns via _id, not id.

docs/docs/guides/8-migration-v1.md[232-244]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1235]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/find-options/operator/In.ts[8-12]
src/find-options/FindOperator.ts[12-67]
test/functional/mongodb/basic/object-id/mongodb-object-id.test.ts[69-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide currently states that `findByIds` was removed from MongoDB APIs too, but it recommends the relational replacement (`findBy` + `In`) which is not translated in the MongoDB codepath.
### Issue Context
MongoDB find methods pass the filter object directly into `collection.find(...)` without converting TypeORM `FindOperator` instances (like `In`) into Mongo operators (like `$in`). Mongo tests also show querying ObjectId columns via `_id`.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]
### Suggested change
Adjust the section to:
1) Clearly label the existing snippet as **SQL/relational**.
2) Add a **MongoDB** snippet, e.g.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's...

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                  )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide recommends replacing findByIds with findBy + In, including for MongoDB,
but MongoDB find/findBy passes the where object directly to the Mongo driver without translating
FindOperator (e.g., In()) into $in. This makes the documented replacement misleading for Mongo
users and can cause queries to return no results.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly claims the replacement applies to MongoEntityManager/MongoRepository and
shows In(...). However, MongoEntityManager’s executeFind builds a query by returning
options.where verbatim (or the conditions object itself) and then hands that object directly to
createEntityCursor, which ultimately calls collection.find(filter) without any conversion layer.
Since In() returns a TypeORM FindOperator("in", ...) object, it will be sent as-is to MongoDB
rather than as a $in expression. The PR’s own internal refactors for Mongo use _id: { $in: ... }
with ObjectId conversion, underscoring that $in is the correct Mongo form.

docs/docs/guides/8-migration-v1.md[232-244]
src/find-options/operator/In.ts[8-12]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1210]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/persistence/SubjectDatabaseEntityLoader.ts[120-151]
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[144-176]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The v1 migration guide states that `findByIds` removal applies to MongoDB APIs too and recommends replacing it with `findBy` + `In()`. In the current MongoDB implementation, `In()` produces a TypeORM `FindOperator` object and Mongo query execution passes the `where` object directly to `collection.find(...)` without translating `FindOperator` into MongoDB operators like `$in`.
### Issue Context
This becomes user-impacting now that `MongoRepository.findByIds`/`MongoEntityManager.findByIds` are removed and the guide is the primary migration path.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide states findByIds was removed from MongoEntityManager, but the PR
reintroduces a public MongoEntityManager.findByIds() method. This makes the docs inaccurate for
users relying on the stated public API changes.

Code

src/entity-manager/MongoEntityManager.ts[R961-993]

+    /**
+     * Finds entities by an array of ids, resolving ObjectId types as needed.
+     * @param entityClassOrName
+     * @param ids
+     */
+    async findByIds<Entity extends ObjectLiteral>(
+        entityClassOrName: EntityTarget<Entity>,
+        ids: any[],
+    ): Promise<Entity[]> {
+        const metadata = this.connection.getMetadata(entityClassOrName)
+        const objectIdInstance = PlatformTools.load("mongodb").ObjectId
+        const cursor = this.createEntityCursor<Entity>(entityClassOrName, {
+            _id: {
+                $in: ids.map((id) => {
+                    if (typeof id === "string") {
+                        return new objectIdInstance(id)
+                    }
+                    if (typeof id === "object") {
+                        if (id instanceof objectIdInstance) {
+                            return id
+                        }
+                        const propertyName =
+                            metadata.objectIdColumn!.propertyName
+                        if (id[propertyName] instanceof objectIdInstance) {
+                            return id[propertyName]
+                        }
+                    }
+                    return id
+                }),
+            },
+        } as Filter<Entity>)
+        return cursor.toArray()
+    }

Evidence

Compliance requires docs to accurately reflect user-facing API changes; the migration guide claims
findByIds was removed from MongoEntityManager, but the PR adds async findByIds(...) without
protected/private, meaning it remains publicly accessible.

Rule 2: Docs updated for user-facing changes
docs/docs/guides/8-migration-v1.md[232-235]
src/entity-manager/MongoEntityManager.ts[961-993]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide says `findByIds` was removed from `MongoEntityManager`, but the PR adds `MongoEntityManager.findByIds()` as a public method (no `protected`/`private`). This makes the docs inaccurate and keeps a deprecated-looking API surface.
## Issue Context
The migration guide explicitly lists `MongoEntityManager` among the APIs where `findByIds` was removed. Internal code paths in this PR call `mongoManager.findByIds(...)`, which also implies the API still exists.
## Fix Focus Areas
- src/entity-manager/MongoEntityManager.ts[961-993]
- src/persistence/SubjectDatabaseEntityLoader.ts[114-119]
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[132-153]
- docs/docs/guides/8-migration-v1.md[232-235]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide says findByIds removal applies to MongoDB APIs and recommends `findBy({ id:
In([...]) })`, but Mongo find paths pass the filter directly to MongoDB with no translation of
TypeORM FindOperator (like In) and Mongo id filtering uses _id (not id). Mongo users
following the guide will likely get empty results or incorrect queries.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly includes MongoDB managers/repositories yet shows the SQL-style In()
replacement. In MongoDB, findBy/find ultimately call collection.find(filter) with the provided
where/filter object; there is no code in the Mongo path that recognizes/rewrites TypeORM
FindOperator (produced by In()) into Mongo $in. Existing Mongo tests also demonstrate querying
ObjectId columns via _id, not id.

docs/docs/guides/8-migration-v1.md[232-244]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1235]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/find-options/operator/In.ts[8-12]
src/find-options/FindOperator.ts[12-67]
test/functional/mongodb/basic/object-id/mongodb-object-id.test.ts[69-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide currently states that `findByIds` was removed from MongoDB APIs too, but it recommends the relational replacement (`findBy` + `In`) which is not translated in the MongoDB codepath.
### Issue Context
MongoDB find methods pass the filter object directly into `collection.find(...)` without converting TypeORM `FindOperator` instances (like `In`) into Mongo operators (like `$in`). Mongo tests also show querying ObjectId columns via `_id`.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]
### Suggested change
Adjust the section to:
1) Clearly label the existing snippet as **SQL/relational**.
2) Add a **MongoDB** snippet, e.g.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                 )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                   )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                  )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide states findByIds was removed from MongoEntityManager, but the PR
reintroduces a public MongoEntityManager.findByIds() method. This makes the docs inaccurate for
users relying on the stated public API changes.

Code

src/entity-manager/MongoEntityManager.ts[R961-993]

+    /**
+     * Finds entities by an array of ids, resolving ObjectId types as needed.
+     * @param entityClassOrName
+     * @param ids
+     */
+    async findByIds<Entity extends ObjectLiteral>(
+        entityClassOrName: EntityTarget<Entity>,
+        ids: any[],
+    ): Promise<Entity[]> {
+        const metadata = this.connection.getMetadata(entityClassOrName)
+        const objectIdInstance = PlatformTools.load("mongodb").ObjectId
+        const cursor = this.createEntityCursor<Entity>(entityClassOrName, {
+            _id: {
+                $in: ids.map((id) => {
+                    if (typeof id === "string") {
+                        return new objectIdInstance(id)
+                    }
+                    if (typeof id === "object") {
+                        if (id instanceof objectIdInstance) {
+                            return id
+                        }
+                        const propertyName =
+                            metadata.objectIdColumn!.propertyName
+                        if (id[propertyName] instanceof objectIdInstance) {
+                            return id[propertyName]
+                        }
+                    }
+                    return id
+                }),
+            },
+        } as Filter<Entity>)
+        return cursor.toArray()
+    }

Evidence

Compliance requires docs to accurately reflect user-facing API changes; the migration guide claims
findByIds was removed from MongoEntityManager, but the PR adds async findByIds(...) without
protected/private, meaning it remains publicly accessible.

Rule 2: Docs updated for user-facing changes
docs/docs/guides/8-migration-v1.md[232-235]
src/entity-manager/MongoEntityManager.ts[961-993]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide says `findByIds` was removed from `MongoEntityManager`, but the PR adds `MongoEntityManager.findByIds()` as a public method (no `protected`/`private`). This makes the docs inaccurate and keeps a deprecated-looking API surface.
## Issue Context
The migration guide explicitly lists `MongoEntityManager` among the APIs where `findByIds` was removed. Internal code paths in this PR call `mongoManager.findByIds(...)`, which also implies the API still exists.
## Fix Focus Areas
- src/entity-manager/MongoEntityManager.ts[961-993]
- src/persistence/SubjectDatabaseEntityLoader.ts[114-119]
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[132-153]
- docs/docs/guides/8-migration-v1.md[232-235]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The migration guide says findByIds removal applies to MongoDB APIs and recommends `findBy({ id:
In([...]) })`, but Mongo find paths pass the filter directly to MongoDB with no translation of
TypeORM FindOperator (like In) and Mongo id filtering uses _id (not id). Mongo users
following the guide will likely get empty results or incorrect queries.

Code

docs/docs/guides/8-migration-v1.md[R232-244]

+### `findByIds`
+
+The deprecated `findByIds` method has been removed from `EntityManager`, `Repository`, `BaseEntity`, `MongoEntityManager`, and `MongoRepository`. Use `findBy` with the `In` operator instead:
+
+```typescript
+// Before
+const users = await repository.findByIds([1, 2, 3])
+
+// After
+import { In } from "typeorm"
+
+const users = await repository.findBy({ id: In([1, 2, 3]) })
+```

Evidence

The guide explicitly includes MongoDB managers/repositories yet shows the SQL-style In()
replacement. In MongoDB, findBy/find ultimately call collection.find(filter) with the provided
where/filter object; there is no code in the Mongo path that recognizes/rewrites TypeORM
FindOperator (produced by In()) into Mongo $in. Existing Mongo tests also demonstrate querying
ObjectId columns via _id, not id.

docs/docs/guides/8-migration-v1.md[232-244]
src/entity-manager/MongoEntityManager.ts[965-983]
src/entity-manager/MongoEntityManager.ts[1198-1235]
src/driver/mongodb/MongoQueryRunner.ts[151-153]
src/find-options/operator/In.ts[8-12]
src/find-options/FindOperator.ts[12-67]
test/functional/mongodb/basic/object-id/mongodb-object-id.test.ts[69-71]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The migration guide currently states that `findByIds` was removed from MongoDB APIs too, but it recommends the relational replacement (`findBy` + `In`) which is not translated in the MongoDB codepath.
### Issue Context
MongoDB find methods pass the filter object directly into `collection.find(...)` without converting TypeORM `FindOperator` instances (like `In`) into Mongo operators (like `$in`). Mongo tests also show querying ObjectId columns via `_id`.
### Fix Focus Areas
- docs/docs/guides/8-migration-v1.md[232-244]
### Suggested change
Adjust the section to:
1) Clearly label the existing snippet as **SQL/relational**.
2) Add a **MongoDB** snippet, e.g.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                  )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

New code uses as unknown as MongoEntityManager and (id: any) which bypasses type safety and
matches the checklist's prohibited any-casts. This can hide real typing issues and make MongoDB-id
normalization logic easier to break during refactors.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-152]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                 )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {

Evidence

PR Compliance ID 4 forbids introducing any casts or similar type-bypass patterns. The new
implementation explicitly adds as unknown as MongoEntityManager and a callback parameter typed as
any.

Rule 4: Remove AI-generated noise
src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The refactor introduces type-bypass casts (`as unknown as MongoEntityManager` and `(id: any)`), which violates the project requirement to avoid `any`-casts/type-safety bypasses.
## Issue Context
The code already branches on `isMongoDb`, so it should be possible to narrow types without `unknown`/`any` and keep id-normalization type-safe.
## Fix Focus Areas
- src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[139-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The MongoDB branch in SubjectDatabaseEntityLoader now calls createEntityCursor(...).toArray()
directly, so any FindManyOptions behavior (projection/skip/take/order and soft-delete filtering)
provided by MongoEntityManager.find() will be ignored. This creates cross-driver inconsistency
(SQL uses setFindOptions(findOptions)), and makes future option changes in this code path silently
ineffective on MongoDB.

Code

src/persistence/SubjectDatabaseEntityLoader.ts[R115-153]

+                    const mongoManager = this.queryRunner
+                        .manager as MongoEntityManager
+                    const metadata = this.queryRunner.connection.getMetadata(
+                        subjectGroup.target,
+                    )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
                          subjectGroup.target,
-                        ) as MongoRepository<ObjectLiteral>
-                    entities = await mongoRepo.findByIds(allIds, findOptions)
+                            {
+                                _id: {
+                                    $in: allIds.map((id) => {
+                                        if (typeof id === "string") {
+                                            return new objectIdInstance(id)
+                                        }
+                                        if (typeof id === "object") {
+                                            if (
+                                                id instanceof objectIdInstance
+                                            ) {
+                                                return id
+                                            }
+                                            const propertyName =
+                                                metadata.objectIdColumn!
+                                                    .propertyName
+                                            if (
+                                                id[propertyName] instanceof
+                                                objectIdInstance
+                                            ) {
+                                                return id[propertyName]
+                                            }
+                                        }
+                                        return id
+                                    }),
+                                },
+                            },
+                        )
+                    entities = await cursor.toArray()
              } else {

Evidence

SubjectDatabaseEntityLoader constructs findOptions and applies it only for SQL via
setFindOptions(findOptions), but the MongoDB branch bypasses options entirely by using a raw
cursor and toArray(). Meanwhile, MongoEntityManager.find() shows the standard Mongo path where
FindManyOptions (select/skip/take/order/withDeleted) are applied and soft-deletes are filtered
unless withDeleted is set.

src/persistence/SubjectDatabaseEntityLoader.ts[99-160]
src/entity-manager/MongoEntityManager.ts[103-140]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`SubjectDatabaseEntityLoader` builds a `findOptions` object (used on SQL via `setFindOptions`) but the MongoDB branch bypasses TypeORM’s standard `find` option handling by using `createEntityCursor(...).toArray()` directly.
### Issue Context
MongoEntityManager’s `find()` applies `FindManyOptions` fields like `select/skip/take/order` and soft-delete filtering (`withDeleted`). The loader’s Mongo path should ideally align with that behavior (and at minimum not silently ignore options).
### Fix Focus Areas
- src/persistence/SubjectDatabaseEntityLoader.ts[99-160]
- src/entity-manager/MongoEntityManager.ts[103-140]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

MongoDB _id normalization logic is duplicated in multiple internal call sites, increasing the
chance of inconsistent behavior if ID-handling evolves. TypeORM already has a centralized helper
(convertMixedCriteria) that supports a broader set of ObjectId-compatible inputs and object-based
criteria building, but the new code re-implements a narrower variant in two places.

Code

src/query-builder/transformer/PlainObjectToDatabaseEntityTransformer.ts[R139-176]

+                    const mongoManager = this
+                        .manager as unknown as MongoEntityManager
+                    const targetMetadata = this.manager.connection.getMetadata(
+                        targetWithIds.target,
                  )
+                    const objectIdInstance =
+                        PlatformTools.load("mongodb").ObjectId
+                    const cursor =
+                        mongoManager.createEntityCursor<ObjectLiteral>(
+                            targetWithIds.target,
+                            {
+                                _id: {
+                                    $in: targetWithIds.ids.map((id: any) => {
+                                        if (typeof id === "string") {
+                                            return new objectIdInstance(id)
+                                        }
+                                        if (typeof id === "object") {
+                                            if (
+                                                id instanceof objectIdInstance
+                                            ) {
+                                                return id
+                                            }
+                                            const propertyName =
+                                                targetMetadata.objectIdColumn!
+                                                    .propertyName
+                                            if (
+                                                id[propertyName] instanceof
+                                                objectIdInstance
+                                            ) {
+                                                return id[propertyName]
+                                            }
+                                        }
+                                        return id
+          ...