enh(test): insert data in parallel

[kailixu]

Description

Please briefly describe the code changes in this pull request.

Checklist

Please check the items in the checklist if applicable.

• Is the user manual updated?
• Are the test cases passed and automated?
• Is there no significant decrease in test coverage?

[gemini-code-assist]

Summary of Changes

Hello @kailixu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request introduces a significant enhancement to the insert_column_value.py system test by refactoring its data insertion mechanism. Instead of sequential execution, the test now leverages Python's ThreadPoolExecutor to perform multiple insert queries concurrently. This change is designed to improve the overall efficiency and reduce the execution time of the test suite, while also ensuring that database operations remain stable and thread-safe under parallel load.

Highlights

• Parallel Test Execution: The insert_column_value.py system test now executes data insertion queries in parallel, significantly speeding up test runs.
• Concurrency Implementation: The concurrent.futures.ThreadPoolExecutor is introduced to manage the parallel execution of insert operations.
• Thread Safety: Each parallel insertion task now initializes its own tdSql instance, preventing potential race conditions and ensuring thread-safe database interactions.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request aims to improve test execution time by running data insertion tests in parallel using a ThreadPoolExecutor. While the move to parallel execution is a good enhancement, there is a critical thread-safety issue in the implementation. A new database connection object is created for each thread, but helper methods called within the threads still use a global, shared connection object. This will lead to race conditions and unpredictable test outcomes. This critical issue must be addressed for the parallel execution to work correctly.

[gemini-code-assist]

While creating a new tdSql instance here is a good step towards thread safety, the _query_check method called by __insert_query_common still uses the global tdSql object, which is not thread-safe.

__insert_query_common creates a local tdSql variable. However, when it calls self._query_check(...) (e.g., on line 318), the _query_check method uses the global tdSql object initialized in the init method.

This will cause race conditions between the parallel threads executing the tests, as they will all share and modify the state of the same tdSql object (e.g., its cursor and query results). This can lead to unpredictable test failures and incorrect results.

To fix this, the thread-local tdSql object should be passed to and used by _query_check and any other helper methods it calls.