MaxIdentifierLength

[kakiyama1018]

Hi,

Currently, what I see happen with MaxIdentifierLength is that the "relational" code truncates identifier strings (table names, column names, etc.) to the specified MaxIdentifierLength value (which defaults to 128 characters).

However, if the first 128 characters of the identifier is the SAME, then the names would clash/duplicated... and hence the table will fail to be created.
Thus, a simple truncation based on MaxIdentifierLength should not be the behavior, but it should rather truncate the string AND add some unique identifier to the name and still be within the MaxIdentifierLength limit.

And currently, it appears that this "relational" code that simply truncates the name cannot be overridden by the EF Core providers, so the provider writes are "stuck" with this issue where by default, unique names can be generated that adheres to the MaxIdentifierLength limit.

Can this be resolved so that identifers can be unique and still honor the MaxIdentifierLength limit?
Or at least allow the EF Core providers to override the implementation the enforces the MaxIdentifierLength limit?

Thank you very much in advance.

NOTE: Based on what we have checked, this issue exists with even with EF Core 2.2.

[kakiyama1018]

Customer Impact:

Let us suppose we have the following class:

class T
{
   int my_special_entity_property_1234; // length of name = 31 chars
   int my_special_entity_property_1235; // length of name = 31 chars
}

And let us suppose that MaxIdentifierLength is set to 30, which is the max identifier length for Oracle DB 11.2. With the current implementation of the "relational" code, it truncates the property name to 30 chars and nothing is done to attempt to generate a unique name for it.

Thus, the following column names will be used for all EF Core versions including 2.2:
my_special_entity_property_123 (length = 30 chars)
my_special_entity_property_123 (length = 30 chars)
... which end up being the same name being used for the column names.... which means that the table will not be created properly.

It will be much nicer for EF Core to generate a unique column name for the two properties... rather than forcing customers to either:

1. rename the properties that make them different
   or
2. use HasColumnName() fluent API or the [Column(....)] data annotations.

[ajcvickers]

@AndriySvyryd Can you verify that this repros with 2.2 RTM?

[AndriySvyryd]

In 2.2 we uniquify truncated identifiers for everything except tables, see https://github.com/aspnet/EntityFrameworkCore/blob/779d43731773d59ecd5f899a6330105879263cf3/src/EFCore.Relational/Metadata/Conventions/Internal/SharedTableConvention.cs#L308

[kakiyama1018]

@AndriySvyryd Can table names be uniquified also, if it's truncated? What's preventing the table name from being uniquified along with the other identifiers? Are there issues if table names are uniquified? If so, what are those issues?

Also, I'm assuming that even if the identifiers are truncated /uniquified, the same truncation/uniquification logic will be used when the tables/columns/etc. need to be altered/migrated or dropped from the DB. Please confirm.

[AndriySvyryd]

@kakiyama1018 I filed #14055 for this. The biggest issue is that it would be a breaking change for some apps.

Yes, but users can always override the generated identifiers.

[ajcvickers]

@kakiyama1018 We're closing this since it was mostly fixed already for 2.2, and the remaining missing work is covered by #14055. We can't fix this in a patch since it would be a breaking change, so we have triaged to fix it in 3.0. For now, I think it's fine for the Oracle provider to do nothing and direct any customers that hit this to specify the table names explicitly.