FIX: executemany RuntimeError when decimals change signs (GH-557)#560
FIX: executemany RuntimeError when decimals change signs (GH-557)#560jahnvi480 wants to merge 9 commits into
Conversation
Root cause: In executemany(), Decimal values in the SMALLMONEY/MONEY range are bound as SQL_VARCHAR with column_size derived from a single sample value's formatted string length. The sample is chosen by _compute_column_type() based on precision/scale, not string length. When the sample is positive (e.g. '1.0' = 3 chars) but the batch contains a negative value (e.g. '-0.1' = 4 chars), the leading '-' makes it exceed the allocated buffer, causing the C++ layer to throw RuntimeError. Fix: After paraminfo is created for auto-detected types, scan all Decimal values in the column to find the true maximum formatted string length and adjust columnSize accordingly. This mirrors the existing pattern used for binary data sizing. Added test_executemany_decimal_sign_change covering: negative-then-positive, positive-then-negative, mixed sign batches, and data correctness verification. Closes #557
📊 Code Coverage Report
Diff CoverageDiff: main...HEAD, staged and unstaged changes
Summary
📋 Files Needing Attention📉 Files with overall lowest coverage (click to expand)mssql_python.pybind.logger_bridge.cpp: 59.2%
mssql_python.pybind.ddbc_bindings.h: 67.9%
mssql_python.row.py: 70.5%
mssql_python.pybind.logger_bridge.hpp: 70.8%
mssql_python.pybind.ddbc_bindings.cpp: 74.6%
mssql_python.pybind.connection.connection.cpp: 76.2%
mssql_python.__init__.py: 77.3%
mssql_python.ddbc_bindings.py: 79.6%
mssql_python.pybind.connection.connection_pool.cpp: 79.6%
mssql_python.connection.py: 85.3%🔗 Quick Links
|
There was a problem hiding this comment.
Pull request overview
Fixes cursor.executemany() failures when batches contain decimal.Decimal values whose formatted length differs across rows (notably due to sign changes), by ensuring the inferred parameter columnSize can accommodate the longest value in the batch. This aligns with the reported RuntimeError in GH-557 and adds regression coverage.
Changes:
- Update
executemanyparameter sizing forDecimalvalues that are bound asSQL_VARCHARby scanning the batch to find the maximum formatted length (GH-557). - Add a regression test that inserts decimal batches with sign changes and verifies inserts succeed and data is retrievable.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| mssql_python/cursor.py | Adjusts executemany auto-detected SQL_VARCHAR column sizing to avoid under-allocation when Decimal string length varies across rows. |
| tests/test_004_cursor.py | Adds a regression test covering executemany with Decimal values that change sign within/between batches (GH-557). |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
…rialized column list
…rialized column list
…rialized column list
…s://github.com/microsoft/mssql-python into jahnvi/fix-executemany-decimal-sign-change-557
| else [] | ||
| ) | ||
| sample_value, min_val, max_val = self._compute_column_type(column) | ||
| sample_value, min_val, max_val, _ = self._compute_column_type(column) |
There was a problem hiding this comment.
"_' is that (4th param) correct coding standard or do we need add a variable name?
There was a problem hiding this comment.
This is correct based on the coding standards, reason we didn't use any variable name here is because it won't be used.
| for row in seq_of_parameters: | ||
| value = row[col_index] | ||
| if value is not None and isinstance(value, (bytes, bytearray)): | ||
| max_binary_size = max(max_binary_size, len(value)) |
There was a problem hiding this comment.
Why above code (line 2277 to 2281) is not able to find the length of the negative number properly?
| # so no extra iteration is needed. | ||
| if ( | ||
| paraminfo.paramSQLType == ddbc_sql_const.SQL_VARCHAR.value | ||
| and max_decimal_len > paraminfo.columnSize |
There was a problem hiding this comment.
paraminfo.columnSize is nothing but max ( max_binary_size ,1) which is expected to work correctly. If we determined that it is not working properly then we should do cleanup in this block of code and remove the unnecessary code and keep the current/latest modified code.
Work Item / Issue Reference
Summary
This pull request fixes an issue with inserting decimal values of varying sign (positive/negative) using
executemany, where the allocated column size could be too small if a negative value's string representation is longer than the sample used for sizing. It ensures the correct column size is used for all rows, preventing runtime errors. A new test is added to verify the fix.Bug fix for decimal handling in
executemany:mssql_python/cursor.py, when inserting decimals asSQL_VARCHAR, the code now scans all rows to determine the maximum formatted string length, ensuring the column size is large enough even when negative values are present.Testing improvements:
test_executemany_decimal_sign_changeintests/test_004_cursor.pyto cover cases where decimals change sign, verifying that no runtime error occurs and the data is correctly inserted and retrieved.