• last updated 57 mins ago
Constraints: committers
Constraints: files
Constraints: dates
Don't collide with multirows created by other tests

Do not enforce that body is a list

Fix typo

Fix typo

Performance improvements:

- set variables from the ns_set and extended variables separately

- collect the values and append to the multirow in one sweep

- when no code body is there, just bulk append the values

This appears to be ~5% faster than db_multirow when both are invoked with a code body and ~30% faster when invoked without (with no prepared statements)

Simplify idiom

Fix behavior of continue in the multirow code block, make the generic fallback behave the same as the postgres version with respect to appending

Test ::xo::dc multirow further

- break and continue behavior in the code block (this will expose a bug)

- appending to an existing multirow

Cleanup leftover line

Extend automated tests to cover new ::xo::dc multirow api

Provide an ::xo::dc api to generate multirows

Notable differences with the classical db_multirow:

- a multirow will always be appended when it already exists. The constraint that the two multirows must have the same columns remains.

- no "if_no_rows_code_block"

- no unclobber

- no subst, do it yourself :-)

- no cache stuff

- support for prepared statements

The remaining behavior has been kept the same, e.g. variables will always be reset to empty string, even if they existed outside of the code block. Compatibility has been checked with knowns idiosyncrasies.

show the question_count in the title only while filling in the exam

use message key

    • -1
    • +1
ensure variable results is defined

Fix prepared statement syntax

Remove test of undocumented format to specify prepared statement

show composite subquestions in question_overview_block

    • -32
    • +47
Provide, as for other interfaces, a Postgres implementation of database foreach that will support prepared statements won't just wrap the db_* api

Make sure the original SQL stays unchanged, as it is used e.g. in the nsv storing the statement and in log messages

Basic test of xo::dc foreach when using prepared statements

This api currently supports the flag, but will ignore it

Strip the possible validation constraint after the first colon character when building the cache key for a parameter, so that the value is stored correctly regardless of the format used to query the parameter

Fixes xowiki.xowiki_test_cases automated test

    • -1
    • +7
Improve the approach with strings containing colons in prepared SQL statements:

we first normalize all strings with a safe placeholder, substitute the variables, then put the strings back in place.

Extend test for prepared statements containing strings with colon characters, exposing that the latest commit won't address all cases

Make test more consistent

Improve the regexp detecting variables in a prepared statement, so that a prepared variable must not be preceded by a semicolon (as before), but also by any character allowed for a variable name

Introduce a test exposing that when a statement is prepared on SQL containing colons, this sould fail because they would be interpreted as variables

Reduce logging as we do downstream

Refactor the query in the folder-chunk page so that on postgres one can enforce permissions in bulk, rather than for each file

Allow to prepare a statement with no parameters (See https://www.postgresql.org/docs/11/sql-prepare.html)

Basic test of the prepared statements feature on ::xo::dc api