Bug #91087 | executemany() should work with REPLACE INTO | ||
---|---|---|---|
Submitted: | 31 May 2018 7:13 | Modified: | 25 Jul 2022 17:12 |
Reporter: | hao chen | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Connector / Python | Severity: | S3 (Non-critical) |
Version: | 2.1.6, 2.1.7 | OS: | Any |
Assigned to: | CPU Architecture: | Any | |
Tags: | Connector/Python, python |
[31 May 2018 7:13]
hao chen
[31 May 2018 7:51]
MySQL Verification Team
Hello hao chen, Thank you for the report. In order to submit contributions you must first sign the Oracle Contribution Agreement (OCA). For additional information please check http://www.oracle.com/technetwork/community/oca-486395.html. If you have any questions, please contact the MySQL community team - https://dev.mysql.com/community/ Thanks, Umesh
[25 Jul 2022 16:59]
Oscar Pacheco
Posted by developer: After analyzing the use case we concluded there is no bug. In this use case, the REPLACE statement is being used five times by leveraging the executemany() method. The user passes a values list (each item being a dictionary) where each item includes different values for primary and unique fields. According to the documentation, when using the REPLACE statement and there is no existing row with the same data regarding the primary or unique keys, a new row is inserted, and that's exactly what is happening (see the log output included in the bug report). From the log output, we observe that five rows were inserted which makes sense since at no time there are values with matching special fields. For instance, by fixing the ID field (primary key) to a constant integer to force the collision we observe that no new rows are added (but the first one), and the row where the ID match happens is updated successfully.
[25 Jul 2022 16:59]
Oscar Pacheco
Posted by developer: After analyzing the use case we concluded there is no bug. In this use case, the REPLACE statement is being used five times by leveraging the executemany() method. The user passes a values list (each item being a dictionary) where each item includes different values for primary and unique fields. According to the documentation, when using the REPLACE statement and there is no existing row with the same data regarding the primary or unique keys, a new row is inserted, and that's exactly what is happening (see the log output included in the bug report). From the log output, we observe that five rows were inserted which makes sense since at no time there are values with matching special fields. For instance, by fixing the ID field (primary key) to a constant integer to force the collision we observe that no new rows are added (but the first one), and the row where the ID match happens is updated successfully.