[Bug] SQL Server JDBC Catalog Column Type Mapping

[khaidot]

Search before asking

• I had searched in the issues and found no similar issues.

Version

4.0.5

What's Wrong?

when querying SQL SERVER catalog from doris, it converts '1' (string) to TRUE

eg.
Select * from mssql.dbo.Table where IsActive = '1'
will be converted to
Select * from mssql.dbo.Table where IsActive = TRUE
if the target column data type is BIT

which will cause this error
SQLServerException: Invalid column name 'TRUE'.

Version 2.1.10 does not have this issue

What You Expected?

No error due to conversion

How to Reproduce?

1. Create SQL server catalog
2. Query a BIT column with filter 'value = '1''
3. Error appears

Anything Else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[zclllyybb]

Breakwater-GitHub-Analysis-Slot: slot_e7ad2f45a6ac

Initial code-level triage points to a SQL Server JDBC predicate pushdown serialization bug, not a new SQL Server BIT column mapping.

What I checked:

• In the 4.0.5 code line, JdbcSQLServerClient.jdbcTypeToDoris() maps SQL Server bit to Doris BOOLEAN.
• The same bit -> BOOLEAN mapping already exists in 2.1.10, so the reported regression is unlikely to be caused by the column type mapping itself.
• For a predicate such as IsActive = '1', Doris can normalize the right side to a boolean because StringLikeLiteral.castToBoolean() treats "1" as BooleanLiteral.TRUE.
• During JDBC scan pushdown, JdbcScanNode.conjunctExprToString() serializes the predicate through toExternalSql(). The legacy BoolLiteral external SQL still prints TRUE / FALSE.

That produces remote SQL like:

... WHERE IsActive = TRUE

For SQL Server bit, bare TRUE is not valid in this context and SQL Server reports it as an identifier, which matches SQLServerException: Invalid column name 'TRUE'. SQL Server-compatible pushdown should render this as 1 / 0, use an equivalent SQL Server cast/parameter form, or skip pushing this rewritten predicate when the dialect cannot accept it.

Suggested next steps for maintainers:

• Add SQL Server-specific boolean literal rendering in the JDBC external SQL path, likely around JdbcScanNode.conjunctExprToString() / expression external SQL serialization, so pushed BoolLiteral(true/false) becomes 1 / 0 for TOdbcTableType.SQLSERVER.
• Add a regression test to the SQL Server external docker JDBC suite. The existing test data already has dbo.test_binary.bit_value; a focused case should cover where bit_value = '1' and preferably where bit_value in ('1', '0') to protect both binary and IN predicate pushdown.
• Please also attach EXPLAIN VERBOSE for the failing query, the exact Doris build commit, and the SQL Server table DDL. The generated QUERY: line should confirm whether the remote SQL contains = TRUE.

Short-term workaround: avoid this pushed predicate shape against SQL Server bit columns, or issue the SQL Server-compatible predicate directly through a JDBC query path that keeps bit_value = 1 on the remote side, until the dialect-specific serialization is fixed.