minor release

RELEASENOTES.md

@@ -1,13 +1,12 @@
-- b5cc07fc (HEAD -> master) unpromote topics list until it works better
-- 0ef8d633 simplify output for listing scenarios and workloads
-- 512759af fix type conversion bug on waitmillis command
-- d0f2152a add sketch of chained flow
-- d95e9de0 add dockerstack diagram
-- 3628cc0f cqld4 incremental process
-- cf03c82b fixed a typo in driver index.md
-- c368b7cc Added Getting Help part to the front page README
-- d6a167c6 release notes script now uses md list form
-- d57835e4 (HEAD -> main) updated scripts for main branch name
+- 6fb23b7b (HEAD -> main) simplify command template prefix
+- 480db201 improve StringSet argument compatibility
+- a1234879 improve error details for missing functions
+- d79ff1fa notes: HashRange and HashInterval do (incl,incl) and (incl,excl) respectively
+- 244217c6 #163 Make NBIO file read errors more helpful
+- cb7d9d16 #163 Make NBIO file read errors more helpful
+- 2a7406e0 #162 Allow hash range functions to span single value ranges
+- 21be4c19 (origin/main) updated release notes
+- d57835e4 updated scripts for main branch name
 - e27b39b0 #158 Simplify YamlStatement Loader part 2, remove previous loader
 - 46b2447d #158 Simplify YamlStatement Loader
 - 941f08c0 example map usage for proposed change

devdocs/linearized/linearized.md

@@ -180,4 +180,17 @@ advanced scenarios:
 -  some ops may be required to produce a value
 -  some ops may be required to produce multiple values
 
+* The carrier of op state should enable the following programmatic constructions:
+  * Metric measuring the service time of the op on failure
+  * Metric measuring the service time of the op on success
+  * Metric measuring the size of the op on success
+  * Hooks for transforming or acting upon the op or cycle before the op executes
+  * Hooks for transforming or acting upon the op or cycle after the op executes, regardless of result
+  * Additional modifiers on the op, as in transformers.
+
+* All op contextual actions should be presented as a function on the op type
+
+* Completion Stages that support the op API should come from built-in template implementations that already include
+  metrics options, logging support, etc.
+
 

driver-cql-shaded/src/main/resources/META-INF/cql-statements.md

@@ -0,0 +1,67 @@
+# CQL Statements
+
+This guide is a work in progress, thus it is not added to any topic index yet.
+
+This guide is a deep dive on how NoSQLBench works with CQL statements specifically with the DataStax
+Java Driver.
+
+## Raw Statement
+
+A raw statement is neither prepared nor parameterized. That is, it is sent as a single string with
+no separate values object. The values must be parsed out during query processing.
+
+In the driver, you might make one of these with the various statement builder APIs, or maybe even
+directly like this:
+
+    new SimpleStatement(
+      "insert into foo.bar (baz) values ('beetle')"
+    );
+
+This is the least efficient type of statement as it will always require the statement structure and
+the values to be parsed out when the statement is handled on the server side.
+
+## Parameterized Statement
+
+A parameterized statement is one where the statement form and the parameters are provided
+separately.
+
+You can create a parameterized SimpleStatement with named parameters like this:
+
+    new SimpleStatement(
+      "insert into foo.bar (baz) values(:bazvalue)",
+      Map.of("bazvalue","beetle")
+    );
+
+This shows the driver conventions for assigning a named parameter anchor in the statement
+`:bazvalue`.
+
+The positional form which uses `?` *is not recommended* for use with NoSQLBench. Named anchors allow
+a basic cross-checking ability that is done automatically by NoSQLBench. Thus, positional use will
+not be covered here.
+
+### non-parameterizable fields
+
+Some elements of CQL syntax, like row-based-access-control principle names are not parameterizable,
+yet you may want to template them at the op template level in nosqlbench. This distinction is very
+subtle, but important. When dealing with these forms, it is best to avoid using prepared statements,
+since each operation will have a different rendered form.
+
+## Prepared Statement
+
+Prepared statements are the fastest way to invoke a CQL operation from the driver as they avoid
+reprocessing the query form on the client and server. However, this means that they act as a
+statement template which can be combined with statement parameters to yield an executable statement.
+Thus, in pracice, all prepared statements are also parameterized statements.
+
+What makes prepared statement faster is that they aren't parsed by the server (or the client) once
+they are prepared. Thus, part of the processing required for a raw statement has already been done
+and cached with prepared statements.
+
+Putting these together, the taxonomy of CQL statement forms supported by the NoSQLBench CQL driver
+are: (TBD))
+
+
+
+
+
+