Description
Issue description
MssqlParameter of type varchar is being treated like nvarchar
Expected Behavior
We are using TypeORM to connect to a MSSQL Server DB. A number of our tables have varchar
columns with indexes on them which we filter on in our WHERE clauses. For example:
andWhere('"name" = :firstName', {
firstName: new MssqlParameter('Bill', 'varchar', 100)
})
In previous versions of TypeORM (e.g. 0.2.33), this parameter was correctly treated like a varchar
in the resulting queries that hit the database. This led to performant queries that properly utilized our desired indexes.
Actual Behavior
However, in versions 0.3.x we are observing this parameter is now being treated as an nvarchar
which is causing implicit conversion and our query performance to plummet.
This seems to have been introduced by this PR: #7933 which appears to be intentionally disregarding the explicitly declared parameter types when they are varchar
or char
. This seems like a very poor solution to the original problem and surely must be causing significant performance issues for anyone querying against varchar
columns like this. We've tried a number of other approaches and every way we declare this parameter it ends up being converted to an nvarchar
before it hits the database.
Steps to reproduce
I don't have a minimal example right now but this appears to be consistently reproducible when querying against a varchar
column in a MSSQL Server DB using a varchar
parameter in the WHERE
clause.
My Environment
Dependency | Version |
---|---|
Operating System | |
Node.js version | 16.17.0 |
Typescript version | 4.7.4 |
TypeORM version | 0.3.16 |
Database | MSSQL Server |
Additional Context
No response
Relevant Database Driver(s)
- aurora-mysql
- aurora-postgres
- better-sqlite3
- cockroachdb
- cordova
- expo
- mongodb
- mysql
- nativescript
- oracle
- postgres
- react-native
- sap
- spanner
- sqlite
- sqlite-abstract
- sqljs
- sqlserver
Are you willing to resolve this issue by submitting a Pull Request?
No, I don’t have the time and I’m okay to wait for the community / maintainers to resolve this issue.