EF core creates migration adding indentation white chars into value

[krzycho1024]

EF core creates migration adding indentation white chars into value when generating .sql script.

Steps to reproduce

create migration:

builder.Property(x => x.Column).HasDefaultValue("Don't\r\n" +
                                                                 "GO\r\n" +
                                                                 "this way\r\n");

run: add-migration test
when creating .sql migration: dotnet ef migrations script -i
indentation is applied inside quoted value

Further technical details

EF Core version: 2.2.3
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Windows 10

[krzycho1024]

[bricelam]

Tricky, tricky. This line would need more information about what can and can't be indented.

https://github.com/aspnet/EntityFrameworkCore/blob/610aa8608d3f912082c56a7d0e4f791cd9b6b211/src/EFCore.Relational/Migrations/Internal/Migrator.cs#L313-L319

The easiest fix would be to not indent the body of the IF statement... but that's ugly for everyone else.

[bricelam]

The workaround is to use...

.HasDefaultValueSql(
    "N'Don''t' + CHAR(13) + CHAR(10) + N'GO' + CHAR(13) + CHAR(10) + N'this way'");

I suppose we could always generate string literals with newlines like this.

[bricelam]

@roji The fix by @lauxjpn seems like the most reasonable way to fix this issue. Do you agree? It has to be done per provider, but anything else will probably require significant plumbing, might be breaking, and will also likely just require providers to update anyway.

[lajones]

Closed fixed by #20304

[lajones]

Note: I filed #20391 to track a similar issue for DefaultValueSql and ComputedColumnSql.

[roji]

This is unfortunately a bit more complicated for PostgreSQL - there are contexts where only a true literal is valid. For example, this breaks test MigrationsNpgsqlTest.Create_table_with_multiline_comments, since the PG comment syntax doesn't accept expressions with concatenation operators.

It may be better to selectively apply the concatenation logic in NpgsqlMigrationsSqlGenerator where we know it's valid (e.g. default value), rather than broadly in the StringTypeMapping's literal generation logic.