• last updated 16 hours ago
Constraints: committers
Constraints: files
Constraints: dates
document public api question_statistics_block

improved spelling

use the built-in bindvars parser (when available) for prepared statements

harden policy

Handle the case of user misconfiguration, where no item type is selected for a pool question: the resulting filter clause would be invalid in this case

split up question_info_block method

Update api

Do not extend the existing multirow, we only enforce that this call will have the same columns

Test that appending to an existing multirow from the db works as expected: when the columns defined via query and extend are the same, this should succeed

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