Add option to disable generation of FKs

[ramiel]

To support myISAM. Not to be confused with migrations.disableForeignKeys config option.

[B4nan]

disableForeignKeys is not an option to "disable generation of FKs". it never was. it only controls if the schema commands will be wrapped in set foreign_key_checks = 0 and set foreign_key_checks = 1. Also note that the default value is true.

[ramiel]

Oh, in version 4 it disabled foreign key constraint creation. What changed here? How do I disable foreign key creation? Not all the mysql DB use the InnoDB engine

[B4nan]

It did not change, it never worked that way.

[B4nan]

What changed is that FKs are not properly diffed, in general schema diffing now works as it should.

[ramiel]

Ok. Question remains. Is there a way to avoid creating foreign key constraints?

[ramiel]

Basically any MySQL db based on https://vitess.io/ won't work with version 5. An example is https://planetscale.com/

[B4nan]

No it is not, there never was one. Feel free to send a PR, but it would have to be a top level configuration (that will be then feeded to the SchemaGenerator methods as part of their options), nothing about migrations, migrations just work with SchemaGenerator.

Note that you still can use v5, you just need to remove the FK queries from your migrations manually if you don't want them there. That is the whole point of migrations, as you have absolute control over that.

[ramiel]

Thanks. I have no time to provide a PR and the codebase is too big, sorry.

Note that you still can use v5, you just need to remove the FK queries from your migrations manually if you don't want them there

Can you explain more about this?

[B4nan]

You have migration file with SQL queries, so you can just remove those you dont want there. Not sure what more you want me to explain about that :]

Note that the codebase might be big, but this problem is about a single file.

https://github.com/mikro-orm/mikro-orm/blob/master/packages/knex/src/schema/SchemaGenerator.ts#L69
https://github.com/mikro-orm/mikro-orm/blob/master/packages/knex/src/schema/SchemaGenerator.ts#L157
https://github.com/mikro-orm/mikro-orm/blob/master/packages/knex/src/schema/SchemaGenerator.ts#L166
https://github.com/mikro-orm/mikro-orm/blob/master/packages/knex/src/schema/SchemaGenerator.ts#L261
https://github.com/mikro-orm/mikro-orm/blob/master/packages/knex/src/schema/SchemaGenerator.ts#L303

(and maybe few more places in that file)

[B4nan]

Let's keep this open, I don't want to sound like I don't see this as something valid. But to me it feels like an edge case, it's been a decade since I came accross someone actually using myisam :D Might be just my bubble :D

[ramiel]

So, let me explain better what I mean. In my code, during startup in dev mode, I have something like this

const generator = orm.getSchemaGenerator();
    
await generator.updateSchema({
  wrap: false,
  safe: true,
  dropDb: false,
  dropTables: false,
});

this way I'm sure DB is up to date with my models. Maybe it's the wrong way, I don't know. If this fails, I print the needed update on console and I run manually. Having an option to disable foreign key contraints would avoid me to run anything manually.

On the other side, I'm not talking about myIsam. I don't know anybody using it. I'm talking about a new generation of cloud-centric mysql based DBs that have very large scalability performances. In a previous message I mentioned one of those (planetscale) and an engine very popular and used (vitess).

I'll try to find the time to work on this and propose a PR, but I'm afrai I really have not much time. What would take me hours or days to be done/tested and so on, it's for sure much less for whoever has already familiarity with the codebase. I'm not saying I want you to do it, I'm just asking if by any chance this can be done.

Thanks for the support

[B4nan]

this way I'm sure DB is up to date with my models. Maybe it's the wrong way, I don't know. If this fails, I print the needed update on console and I run manually. Having an option to disable foreign key contraints would avoid me to run anything manually.

It's not wrong, but I would be quite cautious with this in a production environment (but yeah, with safe: true it should be ok'ish). I wouldn't trust the schema diffing in v4 that much, v5 should be a different story, it's much smarter :]

Note that you are using schema generator, so nothing you specify in migrations config has any effect on that, its a different layer, hence my confusion as you were talking about configuring how migrations work.

And indeed, to me it will probably take an hour or two, to you it can take much more. But you are the one who needs it (actually the first one to ask for it). If you don't have time to collaborate, you can always sponsor the development, especially if this is something you need for a project that will bring you some revenue.

I'm not saying I want you to do it, I'm just asking if by any chance this can be done.

The sad fact is that pretty much all the issues wait for me to work on them. Only a small portion of people will try to contribute, many of them will send an incomplete (often failing) PR and never even reply to my feedback. I usually ask for that in issues like this one, where it really is easy task to achieve. Often I don't even want others to contribute, if it's something touching internals as it can easily have breaking effect to other parts of the codebase.

[ramiel]

As a maintainer of open source projects, I understand you well. I already contributed with a small PR when I could in the past.
Something about the sponsorship. This issue specifically comes form a need of mine in a personal project but we (hypersay.events) use your library in our product (recently released). Your project was in our list of open source projects to give a sign of gratitude, then we were quite busy and distracted and being a small team things get confusing sometimes :)

So yes, definitely expect something from us soon, but I don't want to use sponsorship as a way to push our needs in any way. Good job so far!

It's not wrong, but I would be quite cautious with this in a production environment

No, I'm not using this in production

[varHarrie]

Is there an option to avoid creating foreign key constraints? Just like createForeignKeyConstraints from typeorm.