TST: Make test_sql.py parallelizable 
State: closed

- [x] closes #60378 
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).

Description:

Generated individual uuids for individual hardcoded table name instances throughout the test cases as per the original feature description. Handling the test cases for connections with a shared database state as those which leverage the iris, or type table defined and created in fixtures requires more refactoring if needed to make parallelizable.

On that same note, the parallel safety of these particular connections should be further tested to see if they do require unique table names. 


Labels:
name: Testing
description: pandas testing functions or related to the test suite
name: IO SQL
description: to_sql, read_sql, read_sql_query
name: Stale

Comments:
@WillAyd There seems to be an issue due to the way the drop_table function is currently set up when going through the `future infer strings (without pyarrow)` test. Simply put, when running the tests in parallel, the cleanup operations can fail because one test process might try to check a table's structure right after another process has already deleted that table.

I am thinking this can be handled by simply catching the error that is raised if the table has already been dropped.
With this change, each test should truly create and drop a unique table. There may be some routines that need to adapt to this (either drop being called more consistently or tables names being pass through from the create to the drop process)
Vậy nếu như ví dụ thì nhất quán theo 1 các thức thế nào. Khi không thể đưa
ra dẫn chứng cụ thể hơn. ( đây xem như góp ý đi). Có lẽ sau 2 h nó lại xãy
ra 1 lỗi x2. Hoạc giờ này tôi đang ghim map ngoài thái bình dương thêm 1
lần nữa

Vào CN, 22 thg 12, 2024 lúc 01:50 Matthew Roeschke ***@***.***>
đã viết:

> With this change, each test should truly create and drop a unique table.
> There may be some routines that need to adapt to this (either drop being
> called more consistently or tables names being pass through from the create
> to the drop process)
>
> —
> Reply to this email directly, view it on GitHub
> <https://github.com/pandas-dev/pandas/pull/60595#issuecomment-2558202740>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AKUN6KFCCON3ISH4EME37TT2GWZ55AVCNFSM6AAAAABT7XW7QKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGIYDENZUGA>
> .
> You are receiving this because you are subscribed to this thread.Message
> ID: ***@***.***>
>

Yea sorry @UmbertoFasci I suppose this is a little more complicated than I originally envisioned. You might be able to have the individual fixtures generate both a connection and a table name instead of just a connection. That way the filter can just drop the table name at the end of the fixture, if it exists.

There might be some nuance with views but I'd start with tables first and see how far you get
This pull request is stale because it has been open for thirty days with no activity. Please [update](https://pandas.pydata.org/pandas-docs/stable/development/contributing.html#updating-your-pull-request) and respond to this comment if you're still interested in working on this.
Thanks for the pull request, but it appears to have gone stale. If interested in continuing, please merge in the main branch, address any review comments and/or failing tests, and we can reopen.