Guard against insert() concatenating statements again (#294)

[GermanBluefox]

The bug in #294 is already gone. This adds the regression test that was missing, rather than a fix.

What I checked

The issue was filed against 1.16.1 / 2.2.0 and reports a single query carrying two statements:

INSERT INTO `iobroker`.ts_counter (id, ts, val) VALUES (...);INSERT INTO `iobroker`.ts_number (...) VALUES (...);

Reproducing that exact batch — a counter datapoint, which writes to ts_counter and ts_number in the same flush — against the current builders:

dialect	statements	concatenated
mysql	2	no
postgresql	2	no
mssql	2	no
sqlite	2	no

And _insertValuesIntoDB() sends them one at a time through a recursive next(i), each with its own client.execute, over one borrowed connection. The whole path is sound.

What was missing

Nothing stops it from coming back. A list of queries where one would do is exactly the kind of thing someone "optimizes" by joining — and the only thing in the way was a comment on _insertValuesIntoDB().

test/testInsertStatements.js asserts per dialect that:

• a batch with both counter and value rows yields one statement per table,
• no statement carries a second one behind a semicolon (the trailing ; of a statement is not a match),
• a 1200-row batch chunks into 500 / 500 / 200 without the chunks being glued back together.

Verification

12 cases, in the CI unit list. Control run with the old behaviour restored in the compiled mysql builder (return [query.join('')]):

	with concatenation	as shipped
mysql cases	3 failing	3 passing
total	9 passing, 3 failing	12 passing

177 unit tests pass overall, prettier --check clean.

One thing I did not change

The reported batch also shows a duplicate row — (5, 1676138387812, 53) twice in ts_counter. That is inherent to the counter-reset path: main.ts pushes both the old and the new state on a reset, so a value that is the "new" state of one reset is the "old" state of the next. It is harmless — ts_counter has no primary key, getCounterDiff selects DISTINCT, and equal consecutive values contribute nothing to the summed progression — so I left it alone rather than change counter semantics on the side.

#294 can be closed, and #304 with it if it is the same report, as the commenter suggests.

🤖 Generated with Claude Code