Is there a way to toggle this new behavior OFF? I have an existing application using MySQL backend managed by strapi CMS v3.
If I migrate to strapi v4, the app will break (due to this new implementation of Relation field) and will require a lot of (unnecessary) re-factoring.
Did you find a solution to activate the old behavior?
I would like to use foreign keys instead of the junction tables. In my scenario complex database queries are used to calculate values. If junction tables are used I must add multiple additional joins inside my SQL statements. This could be a performance issue.
Is it possible to add an additional column in the junction table of a many to many relation? Otherwise I must generate an own junction table with the additional column. This table is connected with two one to many relations. In this case strapi generates two additional junction tables, which is totally unnecessary.
Assume you have a years, a country and a settings table. Settings belong to a year and a country (lets assume i could create foreign keys in the settings table, like countryId and yearId). Now i want to have an index that ensures that i only can have one entry for a combination of year and country.
How am I supposed to implement such an index (or validation) if there are no simple foreign keys on one table?
Hmm seeing that this useJoinTable option is hidden and not documented anywhere I suspect this would break the Migration Script as that script doesn’t seem to know about this scenario. It always assumes there is a _link table for the relation lookups (see Code).