Change Details

`IDatabase::buildStringCast()` exists to build an expression to cast a field to a string type, e.g. `CAST( field AS TEXT )`. The current implementations in our code base are: * `Database`: Returns `field`, relying on implicit conversion. * `DatabaseSqlite`: `CAST( field AS TEXT )` * `DatabasePostgres`: `field::text` * `DatabaseOracle`: `CAST( field AS VARCHAR2 )` * MySQL and MSSQL inherit the no-op from `Database`. While the SQL standard doesn't seem to require the implicit conversion to exist, all our supported database engines except PostgreSQL do seem to do implicit conversion (at least where integer→string is needed). However, in {T216183} we discovered that MySQL does not make effective use of the index on a string column when comparing with an integer-valued column. In that case the index is correctly used when an explicit cast of the integer column to a string type is made. Thus this task. Subtasks: [x] Audit (and, if possible, fix) existing calls to `buildStringCast()` for anything that might break [x] in MySQL if it starts producing `CAST( field AS BINARY )`. [x] (optional) in MSSQL if it starts producing `CAST( field AS NVARCHAR )`. [ ] Implement `buildStringCast()` in the remaining subclasses [ ] in `DatabaseMysqlBase` to produce `CAST( field AS BINARY )`. [ ] in `DatabaseMssql` to produce either `field` (preserving the current behavior) or `CAST( field AS NVARCHAR )`. [ ] Update `Database::buildStringCast()` to generically cast too, or make it abstract.

`IDatabase::buildStringCast()` exists to build an expression to cast a field to a string type, e.g. `CAST( field AS TEXT )`. The current implementations in our code base are: * `Database`: Returns `field`, relying on implicit conversion. * `DatabaseSqlite`: `CAST( field AS TEXT )` * `DatabasePostgres`: `field::text` * `DatabaseOracle`: `CAST( field AS VARCHAR2 )` * MySQL and MSSQL inherit the no-op from `Database`. While the SQL standard doesn't seem to require the implicit conversion to exist, all our supported database engines except PostgreSQL do seem to do implicit conversion (at least where integer→string is needed). However, in {T216183} we discovered that MySQL does not make effective use of the index on a string column when comparing with an integer-valued column. In that case the index is correctly used when an explicit cast of the integer column to a string type is made. Thus this task. Subtasks: [x] Audit (and, if possible, fix) existing calls to `buildStringCast()` for anything that might break [x] in MySQL if it starts producing `CAST( field AS BINARY )`. [x] (optional) in MSSQL if it starts producing `CAST( field AS NVARCHAR )`. [x] Implement `buildStringCast()` in the remaining subclasses [x] in `DatabaseMysqlBase` to produce `CAST( field AS BINARY )`. [x] in `DatabaseMssql` to produce either `field` (preserving the current behavior) or `CAST( field AS NVARCHAR )`. [x] Update `Database::buildStringCast()` to generically cast too, or make it abstract.

`IDatabase::buildStringCast()` exists to build an expression to cast a field to a string type, e.g. `CAST( field AS TEXT )`. The current implementations in our code base are: * `Database`: Returns `field`, relying on implicit conversion. * `DatabaseSqlite`: `CAST( field AS TEXT )` * `DatabasePostgres`: `field::text` * `DatabaseOracle`: `CAST( field AS VARCHAR2 )` * MySQL and MSSQL inherit the no-op from `Database`. While the SQL standard doesn't seem to require the implicit conversion to exist, all our supported database engines except PostgreSQL do seem to do implicit conversion (at least where integer→string is needed). However, in {T216183} we discovered that MySQL does not make effective use of the index on a string column when comparing with an integer-valued column. In that case the index is correctly used when an explicit cast of the integer column to a string type is made. Thus this task. Subtasks: [x] Audit (and, if possible, fix) existing calls to `buildStringCast()` for anything that might break [x] in MySQL if it starts producing `CAST( field AS BINARY )`. [x] (optional) in MSSQL if it starts producing `CAST( field AS NVARCHAR )`. [ x] Implement `buildStringCast()` in the remaining subclasses [ x] in `DatabaseMysqlBase` to produce `CAST( field AS BINARY )`. [ x] in `DatabaseMssql` to produce either `field` (preserving the current behavior) or `CAST( field AS NVARCHAR )`. [ x] Update `Database::buildStringCast()` to generically cast too, or make it abstract.