• last updated 11 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
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
    /openacs-4/packages/xowf/lib/inclass-exam.wf
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
    /openacs-4/packages/xowf/tcl/test-item-procs.tcl
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
    /openacs-4/packages/xowiki/tcl/package-procs.tcl
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