• last updated 5 hours ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Use an idiom without expr to fill up the multirow after the body execution

Test the behavior when the multirow contains values in the form "\d+\.": this shows a bug caused by the value retrieval going through an expr, which will "normalize" the value to "\d+\.0"

Performance improvements:

- add with_headers flag to ::xo::dc list_of_lists behaving like the db_list_of_lists counterpart

- use ::xo::dc list_of_lists as internal for ::xo::dc foreach and ::xo::dc multirow to reduce the need for ns_sets

Collect all query results before executing the code to avoid the out-of-pools bug

Implement a test making sure ::xo::dc "loop code-executing" api is not subject to the "out of pools" bug

-prepare flag must not be supplied when not available

Fix regression: the reimplementation of ::xo::dc foreach reintroduced the old "out of pools bug"

The fix makes again use of the ns_set api to free the handle before the code is executed

Remove hack and prefer to document limitation in the automated test

Fix typo and include again the hack for strings with colon char in the fallback implementation of ns_pg_prepare

Fixes xotcl-core.test_prepared_statements automated test

improved spelling

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

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

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.

Remove test of undocumented format to specify prepared statement

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

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