Pull Request Overview

This PR improves database query result handling by introducing named tuple support in fetchone(), enhancing error handling in the C++ bindings, and refactoring the test framework for better maintainability.

• Enhanced fetchone() to support attribute access via named tuples.
• Improved error and logging behavior in the C++ bindings.
• Refactored test cases to use a helper function for table cleanup and row value comparisons.

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

mssql_python/pybind/ddbc_bindings.cpp:1810

• The parameter name in this docstring should be updated to 'row_list' to match the function signature for clarity.

// @param row: A Python object reference that will be populated with a named tuple containing the fetched row data.

The PR follows good practices, is secure, and robustly upgrades the user-facing API. With minor refactoring for efficiency and logging, it would be even better. No memory leaks, deadlocks, or security issues identified. Logic is correct, and changes are well-tested.

As discussed, it would be cleaner and more future-proof to define a dedicated Row class instead of relying on namedtuple generation at runtime. By having a separate Row class, we can:

Encapsulate row behavior: A custom class allows us to centralize logic for attribute and index access, custom formatting, and future enhancements (like dict-like access, type conversions, or richer error handling).
Improve maintainability: Making changes or adding features to row handling (e.g., supporting column name mapping, case-insensitivity, or value transformations) becomes much easier in a single class, without having to manage the quirks of namedtuple limitations.
Enable richer row features: A dedicated class can provide context-aware methods, like .as_dict(), or even hooks for validation, which would be awkward with namedtuples.

Could we refactor this so that fetchone, fetchmany, and fetchall return instances of a Row class, instead of namedtuples or plain tuples? This would keep the codebase cleaner and also pave the way for any future features related to row handling.
Also, the previous tests should be working fine with any introduction of Row related changes.
We should also add new tests for access row data using column name etc.

Requesting some changes w.r.t tests.
Change the PR title to (Row class implementation)