Conversation
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the
✨ Finishing touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Greptile OverviewGreptile SummaryThis PR updates the multi-ORM relation decorators ( Key issue: the new conditional branches in Confidence Score: 3/5
Important Files Changed
Sequence DiagramsequenceDiagram
autonumber
participant E as Entity class (decorated property)
participant D as MultiORM* relation decorator
participant O as getORMType()
participant T as TypeORM decorator
participant M as MikroORM decorator
E->>D: @MultiORM*(target, propertyKey)
D->>O: Determine active ORM
alt ormType == TypeORM
D->>T: Apply TypeORM relation metadata
else ormType == MikroORM
D->>M: Apply MikroORM relation metadata
end
Note over D: Avoids dual registration
Note over D: Bug risk if normalized args not used
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| // Apply TypeORM decorator when using TypeORM | ||
| if (ormType === MultiORMEnum.TypeORM) { | ||
| TypeOrmManyToOne( | ||
| typeFunctionOrTarget as TypeORMTarget<T>, | ||
| inverseSideOrOptions as TypeORMInverseSide<T>, | ||
| options as TypeORMRelationOptions | ||
| )(target, propertyKey); |
There was a problem hiding this comment.
[P0] TypeORM ManyToOne decorator can receive the options object as the inverse-side argument.
In MultiORMManyToOne, when inverseSideOrOptions is an object it is treated as options and inverseSideProperty remains unset, but the TypeORM branch still calls TypeOrmManyToOne(..., inverseSideOrOptions as TypeORMInverseSide<T>, ...). Under TypeORM, calls like MultiORMManyToOne(User, { nullable: true }) will pass that options object as the inverse side and likely break relation metadata registration.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/core/src/lib/core/decorators/entity/relations/many-to-one.decorator.ts
Line: 73:79
Comment:
[P0] TypeORM ManyToOne decorator can receive the *options object* as the inverse-side argument.
In `MultiORMManyToOne`, when `inverseSideOrOptions` is an object it is treated as `options` and `inverseSideProperty` remains unset, but the TypeORM branch still calls `TypeOrmManyToOne(..., inverseSideOrOptions as TypeORMInverseSide<T>, ...)`. Under TypeORM, calls like `MultiORMManyToOne(User, { nullable: true })` will pass that options object as the inverse side and likely break relation metadata registration.
How can I resolve this? If you propose a fix, please make it concise.| // Apply TypeORM decorator when using TypeORM | ||
| if (ormType === MultiORMEnum.TypeORM) { | ||
| TypeOrmOneToOne( | ||
| typeFunctionOrTarget as TypeORMTarget<T>, | ||
| inverseSideOrOptions as TypeORMInverseSide<T>, | ||
| options as TypeORMRelationOptions | ||
| )(target, propertyKey); |
There was a problem hiding this comment.
[P0] TypeORM OneToOne decorator can receive the options object as the inverse-side argument.
MultiORMOneToOne normalizes params such that if inverseSideOrOptions is an object it becomes options and inverseSideProperty remains unset, but the TypeORM branch still passes inverseSideOrOptions as the inverse-side arg. Under TypeORM, calls like MultiORMOneToOne(Profile, { cascade: true }) will end up passing the options object as the inverse side, which can break relation metadata.
Prompt To Fix With AI
This is a comment left during a code review.
Path: packages/core/src/lib/core/decorators/entity/relations/one-to-one.decorator.ts
Line: 73:79
Comment:
[P0] TypeORM OneToOne decorator can receive the *options object* as the inverse-side argument.
`MultiORMOneToOne` normalizes params such that if `inverseSideOrOptions` is an object it becomes `options` and `inverseSideProperty` remains unset, but the TypeORM branch still passes `inverseSideOrOptions` as the inverse-side arg. Under TypeORM, calls like `MultiORMOneToOne(Profile, { cascade: true })` will end up passing the options object as the inverse side, which can break relation metadata.
How can I resolve this? If you propose a fix, please make it concise.![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
🤖 Augment PR SummarySummary: This PR updates the multi-ORM relation decorators to apply only the active ORM’s decorators at runtime, and adjusts Nx project dependencies to forward parameters. Changes:
Technical Notes: ORM selection is driven by 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
| }) | ||
| )(target, propertyKey); | ||
| // Determine which ORM is in use | ||
| const ormType = getORMType(); |
There was a problem hiding this comment.
getORMType() is evaluated when decorators run (class definition time), so if DB_ORM isn’t set before entity modules are imported it will default to TypeORM and skip registering MikroORM relation metadata. That can lead to missing relations in MikroORM runtime (or vice‑versa) depending on import order/config initialization.
Other Locations
packages/core/src/lib/core/decorators/entity/relations/many-to-one.decorator.ts:71packages/core/src/lib/core/decorators/entity/relations/one-to-many.decorator.ts:60packages/core/src/lib/core/decorators/entity/relations/one-to-one.decorator.ts:71
🤖 Was this useful? React with 👍 or 👎, or 🚀 if it prevented an incident/outage.
1 participant
PR
Please note: we will close your PR without comment if you do not check the boxes above and provide ALL requested information.
Summary by cubic
Make relation decorators apply only the active ORM (TypeORM or MikroORM) using getORMType, fixing multi-ORM build/runtime conflicts. Update Nx project configs to forward params in dependsOn for consistent env/config during builds.
Written for commit ae44709. Summary will update on new commits.