Hey all,
Yes I did close and lock the issue as it’s not something we plan to support but I wanted to pop in here and give a little more reason why we can’t just add a flag or configuration option to disable this.
I’m sure as many of you understand, every configuration option we add we need to be able to support it, test it, and when things break we are inevitably responsible to fix it. By disallowing foreign key constraints it means we are saying that we support users running their databases in a slightly dangerous state (I’m sure that’s widely open to interpretation, but not something I wish to debate here). And while for most of the free and open source users much like yourselves this is no problem, there are many things that we state “do at your own risk” when it comes to Strapi itself but all of these options require customization.
The issue happens when you look at our enterprise customers and eventually our cloud, we build Strapi in such a way that many huge companies are using it for mission critical applications and we need to ensure that Strapi it safe, stable, and secure and this requires us to make hard choices on what we can and cannot implement. We as a team made the decision to properly implement foreign key constraints as part of Strapi v4 and this was an engineering decision that we are not currently willing to rollback to support a small niche (there are many other hybrid/horizontally scaling database options such as cockroachDB that a community user is currently working on implementing: https://github.com/strapi/strapi/pull/12346) or much better clustering options such as MariaDB’s Galera clusters (which support multi-masters as well!).
At the end of the day your project is yours, the code is yours, and the benefit to Strapi is you can customize it all the way down to the core level using patch-package so if you wish to remove FQs on your own project you have that freedom, if you want to fork Strapi’s database package and resolve it differently you have that freedom, or if you wanted to fork Strapi in it’s entirety you have that freedom as well.
We have to make decisions for the bulk of our users and there is some cases where we simply have to say “no, we can’t do this” for various reasons. In this specific case it’s pretty much 90% maintenance overhead that we are simply not willing to take on. Exactly the same reason we don’t have Microsoft’s SQL Server or OracleDB as database options in Strapi even though Knex supports them.