TST: Make test_sql.py parallelizable

[UmbertoFasci]

• closes TST: Make test_sql.py parallelizable #60378
• All code checks passed.

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.

[AdLThinhRose]

???

[UmbertoFasci]

@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.

[mroeschke]

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)

[AdLThinhRose]

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 <#60595 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKUN6KFCCON3ISH4EME37TT2GWZ55AVCNFSM6AAAAABT7XW7QKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNJYGIYDENZUGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[WillAyd]

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