[CONPY-267] Behavior of executemany() is inconsistent between MariaDB and non-MariaDB servers Created: 2023-06-28  Updated: 2023-06-28

Status: Open
Project: MariaDB Connector/Python
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: markus makela Assignee: Georg Richter
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Problem/Incident
is caused by CONPY-165 Optimize executemany() for non MariaD... Open
Relates
relates to CONPY-165 Optimize executemany() for non MariaD... Open

 Description   

The way executemany() fails depends on whether the server supports the bulk insertion protocol or not. For servers that support it, if any of the rows fails to insert, no rows are inserted. For server that do not support it, all rows that precede the error are inserted but all rows after it are not.

The following program demonstrates the problem.

#!/usr/bin/env python3
import mariadb
conn = mariadb.connect(
  user="maxuser",
  password="maxpwd",
  host="127.0.0.1",
  port=4006,
  database="test"
)
print(conn.get_server_version())
# Get Cursor
cur = conn.cursor()
values = [
  ("a", ),
  ("b", ),
  ("c", ),
  ("d", ),
  ("a", ),
  ("e", ),
  ("f", ),
]
cur.execute("CREATE OR REPLACE TABLE t1 (data CHAR(30) NOT NULL PRIMARY KEY)")
try:
  cur.executemany("INSERT INTO t1 VALUES (?)", values)
except Exception as e:
  print(e)
cur.execute("SELECT * FROM t1")
print([x for x in cur.fetchall()])

This is what when I tested it with a fake version string of 8.0.1-maxscale:

[markusjm@monolith python]$ ./bulk_execute.py 
(8, 0, 1)
Duplicate entry 'a' for key 'PRIMARY'
[('a',), ('b',), ('c',), ('d',)]
[markusjm@monolith python]$ ./bulk_execute.py 
(10, 11, 3)
Duplicate entry 'a' for key 'PRIMARY'
[]


Generated at Thu Feb 08 03:31:29 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.