Strapi Version: 4.2.3
Operating System: Windows
Node Version: 16.14.2
I have been using V3 and I’m quite happy with it, however, since it will probably lose support I’m trying to learn V4.
This question is associated with Mysql Relations. In v3, when I create a one-to-many relation, it would create a foreign key in one of the tables to represent that relation (expected behaviour). That allowd us to manage the complexity of our database fairly well.
In V4, when I create a one-to-many relation it creates a new table table1_table2_links. A junction table is not really needed to represent this realtion and increases the database complexity. This can be troublesome especially when one has to write raw SQL queries…
Is it possible to avoid the creation of a table table1_table2_links and generate the foreign key directly on the respective table in a V3 fashion?
Thank you in advance
Unfortunately not, in order to build a specific set of features in the future (mainly content versioning) we needed to add that central table to help handle a primary use-case which is versioning of relations.
In the future we want users to be able to have a published version of an entity but also be able to work on at least 1 draft and then through the process of things like review workflows and publication automations be able to release that draft into the published state but also be able to rollback if needed.
As you can imagine normally in a oneToMany (or any relation really that would normally just rely on the 2 tables) this makes it impossible to have as it would effectively become a manyToMany relation. That central table will be used as a means to build that manyToMany but keep the logic as a oneToMany.
We introduced this for all content-types in v4 as a means to build the foundations of the features we want to build but we wanted to prevent the sins of our past by helping to prevent future breaking changes that would require another complex migration in the future. Obviously we can predict all future outcomes but we are certainly trying our best.
If you don’t mind me asking, what are you attempting to do in your RAW queries as there might be a better/easier way for you?
I need to update many tables at once, however, if something fails, I have to rollback the operation. Since strapi does not support transactions I was trying to do it by myself with raw SQL. In V3 it was ok because I could create the DB as I wanted. In V4 I feel so disappointed with strapi because it has so many questionable design decisions… So much potential wasted… I think is nice to come up with new features, but it is really a bad idea to force people to use them. It’s always better to give the developer freedom.
As a back-end developer, I think everyone wants to control their Database and be able to manipulate it for their needs. Being forced to addopt weird patterns for the sake of some features I won’t probably use or need really makes me think twice about adopting strapi for my projects.
try use option “useJoinTable: false”
Thank you so much @smoothdvd
Do I have to add it manually to every relation?
@Filipe_Cunha I do understand where you are coming from and this is what largely separates a headless CMS from an API framework. We have to take design decisions that related to the software functioning on a headless CMS level with features needed by some but not all and this requires us to build things that are able to cover both of those use-cases.
To have an option to disable those join tables on project creation would result in a very manual and risky migration process should you ever want to enable them. Likewise giving the option to disable them. Our solution was to enforce their usage for everyone to make future feature development easier on us (less tests needed to cover multiple use cases) because we can predict the state that a users application will be in.
This is exactly the same reason we dropped support for MongoDB because there were two major states a users database could be in and we had to account for both as we developed features which lead to a lot of frustration when something would work on database type A but not type B.
We certainly do try to give as much freedom to the end user by default but in some cases we do have to make choices that generalize Strapi’s usage and not specialize in one particular use-case, as you can image there are practically an unlimited number of use-cases; to the point where you need to build software that works on all of them (or least say 80% of them) is impossible without saying “yeah your use-case may not work with us unless you do what we are doing” and this is both normal and expected.