create_table_from_entity ignores max identifier length

[cemoktra]

Description

create_table_from_entity create a foreign key name, that can get quite long. In my case 69 characters. The maximum in MySQL is 64 characters.

Steps to Reproduce

Generate schema for a tables that reference each other and have quite long names. Like 20 characters.

Expected Behavior

Foreign key name might be trimmed to 64 characters. Or add a possibility to specify foreign key names.

[billy1624]

Hey @cemoktra, thanks for the report! You can override name of the foreign key via one of

• https://github.com/SeaQL/sea-orm/blob/b59f3c58deb04f70476a04263c14f9d21d9596ef/tests/common/features/active_enum_child.rs#L16-L25
• https://github.com/SeaQL/sea-orm/blob/b59f3c58deb04f70476a04263c14f9d21d9596ef/src/entity/relation.rs#L170-L174

[ikrivosheev]

@billy1624 maybe we can make a compiler_error. What do you think?

[billy1624]

Seems the maximum allowed length of index / foreign key name were 64 characters or no limit depending on the db backend.

• For MySQL, MariaDB and PostgreSQL, it's 64 characters
• No such limit for SQLite

I think we should throw a error / warning on SeaQuery side @ikrivosheev Is it possible to throw a compiler error at compile time?

[ikrivosheev]

@billy1624 I will try to do this...

[billy1624]

Thanks! @ikrivosheev

[billy1624]

As I mentioned above you can override the generated foreign key name, https://github.com/SeaQL/sea-orm/issues/720#issuecomment-1125967188. And, @ikrivosheev, I don't think we can produce a error / warning for long foreign key name at compile time because the name isn't a constant that we can evaluate at compile time.

[tyt2y3]

Actually, I think we can leave it as is. It might be a good idea for the linter, though

[billy1624]

• For MySQL, MariaDB and PostgreSQL, it's 64 characters
• No such limit for SQLite

Hey everyone, would truncating the name of index/foreign key exceed those limit be a good idea? i.e. implementing the query writer in db dependent manner inside SeaQuery.

[tyt2y3]

I don't think truncation is a correct behaviour. And if it becomes a runtime error, I guess not much value than it becoming a SQL error.