[noahisdai]

Description of change

Follow-up to typeorm#12884, based on de58583. Fixes the five open Qodo findings, with separate commits per finding.

Commit	Finding
66e4814 perf: cache resolveDriverColumn projections per driver	Bulk inserts cloned metadata per column and row. The projection is now cached per driver and override, and cleared in build()
0f39016 fix: drop inherited collation from non-collatable overrides on all drivers	SQL Server, CockroachDB and Oracle emitted COLLATE on non-text overrides. Each driver now declares withCollationColumnTypes, replacing the Postgres-only set
ec576ef + 86c55ab keep MySQL override numeric defaults in MysqlDriver	A decimal(4,2) default of 1.23 overridden to varchar was emitted as '1'. Handled in MysqlDriver.normalizeDefault, only for columns with an override
a378bad fix: check MariaDB override timestamp precision in the MySQL drivers	MariaDB was missing from the precision checks. The DEFAULT check moves from TableUtils into MysqlDriver / AuroraMysqlDriver
c60b5b1 fix: bind SQL Server lengths as numbers and max as the mssql MAX constant	parametrizeValue passed the length string ("max", "100") behind as any. Lengths are now numbers and max is mssql.MAX, matching MssqlParameter's length?: number; the generated SQL is unchanged
bdb0a61, 2ba004e	Optional chaining in the collation check; functional tests on the repo template

MariaDB's precision rules differ from MySQL's (checked on 10.11.19 and 12.3.3, strict mode):

Clause	MariaDB	Check
ON UPDATE less precise than the column	ERROR 1294 Invalid ON UPDATE clause	Rejected (must match, as on MySQL)
ON UPDATE more precise	Accepted, silently saved at the column precision	Rejected
DEFAULT more precise	Accepted, silently saved at the column precision	Rejected
DEFAULT less precise	Accepted as written	Allowed

Tested

Driver	Result
SQL Server 2025, CockroachDB 24.3, MySQL 9, MariaDB 10.11	New functional tests pass. Without the fixes they fail with Expression type int is invalid for COLLATE clause, COLLATE declaration for non-string-typed column, Invalid ON UPDATE clause, and the default stored as 1
Postgres 17, better-sqlite3, sqljs	Existing dialect-types, columns and schema-builder suites
Oracle, Aurora MySQL	Not run against a database (unit tests only)

Unit tests: 354 passing. After the bind change, the SQL Server columns, insert, update and repository suites pass (103), including the mssql-parameters MAX bind test. The schema-builder suites on SQL Server hit request timeouts on my machine (emulated on Apple Silicon). The one I rechecked, the FK change column test, passes with a longer request timeout.

AI-assisted implementation and testing.

Pull-Request Checklist

• Code is up-to-date with the master branch (de58583)
• This pull request links a relevant issue: refs Support per-dialect column types on @Column, e.g. dialectTypes: { postgres: 'jsonb' } typeorm/typeorm#12874
• There are new or updated tests validating the change
• Documentation has been updated to reflect this change: N/A, no public API change

[noahisdai]

Qodo's finding on SQL Server max binds suggested converting the "max" length into the driver's numeric MAX value before creating MssqlParameter. I did that in c60b5b1: lengths are now passed as numbers, max as mssql.MAX, and the as any on the length is removed.

It reaches beyond dialectTypes, though. parametrizeValue is shared by all SQL Server columns, so existing columns with a length now pass numbers too, for example 65535 instead of "MAX". The generated SQL is the same and the SQL Server suites pass, but it's a change outside this PR's scope.

Should I keep it as is, or limit it to columns with a dialectTypes override?

[noahisdai]

Hi, @xue-ding-e
Do you think you'll have time to review the pull request?

[xue-ding-e]

Thanks @noahisdai. I reviewed the scope question at c60b5b1. Please keep the numeric length / mssql.MAX conversion limited to columns with an active mssql dialectTypes override in this PR, for example by checking column.dialectTypes?.[this.options.type] !== undefined.

Please retain the three MAX-type cases and the bounded override case, and add coverage for:

• An active mssql override that inherits the logical column’s length.
• Columns without an override retaining their previous binding behavior, for both bounded and MAX lengths.
• Columns with only another dialect’s override retaining their previous behavior.

The existing logical-MAX test currently expects the broader change, so that expectation would need to change with the narrower scope. A general SQL Server length-binding normalization can be evaluated separately. This is a scope recommendation, not a claim that the broader change has a demonstrated regression.

I have not independently rerun the live-database matrix. This is not full-PR approval. AI-assisted review.