You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
person Person @relation(fields: [personId], references: [id])
165
+
teamId Int @map("team_id")
166
+
team Team @relation(fields: [teamId], references: [id])
167
+
168
+
@@map("team_members")
169
+
}
170
+
```
171
+
{% endtab %}
172
+
{% endtabs %}
112
173
113
174
`@adminjs/relations` is adapter-agnostic which means you can use it regardless of the database adapter you had installed. Nevertheless, some ORMs automatically generate and manage junction tables for you without you having to actually create entities for them in your codebase. This will not work with AdminJS and you will have to create actual entities for junction tables and register them as AdminJS resources since AdminJS uses them to find your `M:N` records.
114
175
@@ -176,6 +237,10 @@ type RelationsFeatureConfig = {
176
237
177
238
### One-To-Many
178
239
240
+
{% hint style="warning" %}
241
+
If using Prisma, configure the `joinKey` and `inverseJoinKey` options by providing the relation names instead of foreign keys, for example: `organization` instead of `organizationId`
242
+
{% endhint %}
243
+
179
244
According to the database structure described above as well as the presented configuration options of `owningRelationSettingsFeature`, this is how you can add this feature to `Organization` resource which can have many `Persons` and `Offices`
0 commit comments