fix: EXPOSED-283 Date/Time defaults falsely trigger ALTER statements

[joc-a]

⚠️ Please review commit by commit. I want to rebase and merge instead of squash and merge.

Date/Time column type defaults false trigger ALTER statements because of a mismatch when comparing the default value obtained from the metadata (which Exposed sanitizes) with the formatted default value of the column type. The following are the mismatches that were fixed in this PR.

Mismatches for timestamp column type:

1. PostgreSQL and PostgresSQLNG

Default value from metadata: '2024-02-07 12:42:26.251'::timestamp without time zone
Default value formatted by Exposed: '2024-02-07T12:42:26.251'

2. Oracle and H2 Oracle

Default value from metadata: TIMESTAMP '2024-02-07 12:42:27.453
Default value formatted by Exposed: TIMESTAMP '2024-02-07 12:42:27.453'

3. SQL Server

Default value from metadata: 2024-02-07T12:42:25.31
Default value formatted by Exposed: '2024-02-07T12:42:25.31'

4. MySQL and MariaDB

Default value from metadata: 2024-02-07 12:42:24.508000
Default value formatted by Exposed: '2024-02-07T12:42:24.508'

5. H2 (except for H2 Oracle)

Default value from metadata: 2024-02-07T12:42:23.494
Default value formatted by Exposed: '2024-02-07T12:42:23.494'

Mismatches for timestampWithTimeZone column type:

1. PostgreSQL and PostgresSQLNG

Default value from metadata: '2024-02-07 14:55:28.1+00'::timestamp with time zone
Default value formatted by Exposed: '2024-02-07T23:55:28.100+09:00'

2. Oracle

Default value from metadata: TIMESTAMP '2024-02-07 23:55:29.776000 +09:00
Default value formatted by Exposed: TIMESTAMP '2024-02-07 23:55:29.776000 +09:00'

3. H2 Oracle

Default value from metadata: TIMESTAMP '2024-02-07 14:55:24.9
Default value formatted by Exposed: TIMESTAMP '2024-02-07T23:55:24.900+09:00'

4. SQL Server and H2 (except for H2 Oracle)

Default value from metadata: 2024-02-07T23:55:26.812+09:00
Default value formatted by Exposed: '2024-02-07T23:55:26.812+09:00'

5. MySQL 8

Default value from metadata: 2024-02-07 14:55:25.749000
Default value formatted by Exposed: '2024-02-07 23:55:25.749000+09:00'

Mismatches for datetime column type:

1. PostgreSQL and PostgresSQLNG

Default value from metadata: '2024-02-08 00:02:34.935'::timestamp without time zone
Default value formatted by Exposed: '2024-02-08T00:02:34.935'

2. Oracle and H2 Oracle

Default value from metadata: TIMESTAMP '2024-02-08 00:02:36.459
Default value formatted by Exposed: TIMESTAMP '2024-02-08 00:02:36.459'

3. MySQL and MariaDB

Default value from metadata: 2024-02-08 00:02:45.394000
Default value formatted by Exposed: '2024-02-08T00:02:45.394'

4. SQL Server and H2 (except for H2 Oracle)

Default value from metadata: 2024-02-08T00:02:33.662
Default value formatted by Exposed: '2024-02-08T00:02:33.662'

Mismatches for date column type:

1. PostgreSQL and PostgresSQLNG

Default value from metadata: '2024-02-01'::date
Default value formatted by Exposed: '2024-02-01'

2. Oracle and H2 Oracle

Default value from metadata: DATE '2024-02-01
Default value formatted by Exposed: DATE '2024-02-01'

3. SQL Server and H2 (except for H2 Oracle)

Default value from metadata: 2024-02-01
Default value formatted by Exposed: '2024-02-01'

4. MySQL and MariaDB

Default value from metadata: 2024-02-01
Default value formatted by Exposed: '2024-02-01'

Mismatches for time column type:

1. PostgreSQL

Default value from metadata: '00:11:17.34'::time without time zone
Default value formatted by Exposed: '00:11:17.34'

2. Oracle and H2 Oracle

Default value from metadata: TIMESTAMP '1900-01-01 00:11:12
Default value formatted by Exposed: TIMESTAMP '1900-01-01 00:11:12'

3. SQL Server and H2 (except for H2 Oracle)

Default value from metadata: 00:11:16.088
Default value formatted by Exposed: '00:11:16.088'

4. MySQL and MariaDB

Default value from metadata: 00:11:13
Default value formatted by Exposed: '00:11:13.431'

[bog-walk]

@joc-a @e5l A though about valueAsDefaultString() and how much it duplicates valueToString():

The new functions create strings that match the metadata exactly and the only place valueAsDefaultString() seems used is in processForDefaultValue(), which does 3 things:

• generates DDL for a column
• registers column arguments for a parameterized statement
• used for metadata comparisons

This means all generated SQL with defaults is going to now be different when logged, which works fine. So maybe it would be worth assessing if it would be possible to use this new logic directly inside of the original functions instead. Or at least directly inside the issue source, at LiteralOp, so that the 'correct' SQL string is being used at the first origin, and leave processForDefaultValue() unchanged:

class LiteralOp<T>(
    override val columnType: IColumnType,
    val value: T
) : ExpressionWithColumnType<T>() {
    override fun toQueryBuilder(queryBuilder: QueryBuilder): Unit = queryBuilder {
        // +columnType.valueToString(value)
        +columnType.valueAsDefaultString(value)
    }
}

I guess my overall thought is: Could valueAsDefaultString() be dropped? And either valueToString() gets refactored for literals or nonNullValueAsDefaultString() does all the heavy lifting? For the latter, it would keep the new logic, but could call a common utility function first to trim if needed and check Expression subtypes.

The majority of column types will definitely need to override nonNullValueAsDefaultString(), so I think it'd be great if the goal was to extract all column type logic from both SchemaUtils.dbDefaultToString() and processForDefaultValue(). So maintainers wouldn't have to search in 3 different files for default column behavior and we could one day do something simple like this at the main culprit line in SchemaUtils.addMissingColumnsStatements():

val incorrectDefaults = existingCol.defaultDbValue != col.dbDefaultValue?.let {
    columnType.nonNullValueAsDefaultString(it)
}

[e5l]

@joc-a, please check CI

[joc-a]

@bog-walk My initial approach was to change the nonNullValueToString implementation to match the default value returned by the column's metadata. However, this approach hits a wall with some dialects for the timestamp with time zone column type, because the default value returned for some dialects omits the time zone entirely, and for other dialects, it is always stored using the UTC time zone (thereby losing the original specified time zone). Matching that behaviour would result in a loss of the information seen by users when they log the SQL statements generated by Exposed.
I do want to refactor this code and make some improvements after it is merged (to keep this PR limited to this fix).