diff --git a/driver-direct/src/main/java/io/nosqlbench/driver/direct/DirectActivity.java b/driver-direct/src/main/java/io/nosqlbench/driver/direct/DirectActivity.java
deleted file mode 100644
index 799e8f692..000000000
--- a/driver-direct/src/main/java/io/nosqlbench/driver/direct/DirectActivity.java
+++ /dev/null
@@ -1,21 +0,0 @@
-package io.nosqlbench.driver.direct;
-
-import io.nosqlbench.engine.api.activityapi.core.Activity;
-import io.nosqlbench.engine.api.activityconfig.yaml.OpTemplate;
-import io.nosqlbench.engine.api.activityimpl.ActivityDef;
-import io.nosqlbench.engine.api.activityimpl.OpDispenser;
-import io.nosqlbench.engine.api.activityimpl.uniform.StandardActivity;
-
-import java.util.function.Function;
-
-public class DirectActivity extends StandardActivity NBParams is the main entry point into accessing parameters in a type-safe way.
* It provides a reader interface which normalizes all access patterns for reading
- * configuration parameters from a variety of sources.
- *
- * NBParams not a general purpose data interface. It is a parameter reading interface.
+ * configuration parameters from a variety of sources. NBParams is not a general purpose data interface. It is a named parameter reading interface.
* As such, all data which is presented for reading must be named at every level.
* This means that index access such as '[3]' that you might see in other access
- * vernaculars is NOT supported.
- *
- * However, multiplicity is allowed at the API level in order to support reading
+ * vernaculars is NOT supported. However, multiplicity is allowed at the API level in order to support reading
* zero or more of something when the number of provided elements is intended to
- * be user-specified. In this usage, direct indexing is not intended nor allowed,
+ * be configurable. In this usage, direct indexing is not intended nor allowed,
* but order is preserved. This means that if there are any dependency relationships
* within multiple elements at the same level, the developer can rely on them
- * being provided in the order specific by the user or underlying configuration source.
- * To be crystal clear, direct indexing within configuration parameters is highly
- * discouraged and should not be supported directly by this API.
- *
- * When configuration elements are named within the element definition, regardless
+ * being provided in the order specified by the user or underlying configuration source. When configuration elements are named within the element definition, regardless
* of the source, these names can be taken as naming structure. To enable this, simply
- * provide a name property on the element.
+ * provide a name property on the element. If an element contains a property named name, then the value of this property
* is taken as the name of the element. This is useful in certain contexts when you
* need to define a name at the source of a configuration element but expose it
* to readers. This means that an element can be positioned with a hierarchic structure
- * simply by naming it appropriately.
+ * simply by naming it appropriately. This API allows a developer to choose the structural model imposed on
* configuration data. Specifically, you must choose whether or not to consume the
* parameter data as a set of properties of one element instance, or as as set
- * of elements, each with their own properties.
+ * of elements, each with their own properties. The one element access interface is mean to provide basic support for
* parameterizing a single entity. The names of the parameters surfaced at the
* top level should map directly to the names of properties as provided by the
* underlying data source. This is irrespective of whatever other structure may
* be contained within such properties. The key distinction is that the top level
* names of the configuration object are available under the same top-level names
- * within the one element interface.
- *
- * As data sources can provide either one or many style results, it is important
+ * within the one element interface. As data sources can provide either one or many style results, it is important
* that each data source provide a clear explanation about how it distinguishes
- * reading a single element vs reading (possibly) multiple elements.
- *
- * When explicitly reading a single element, the underlying data source must provide
+ * reading a single element vs reading (possibly) multiple elements. When explicitly reading a single element, the underlying data source must provide
* exactly one element OR provide a series of elements of which some contain
* name properties. Non-distinct names are allowed, although the last element
* for a given name will be the only one visible to readers. It is an error for the
* underlying data source in this mode to be null, empty, or otherwise provide zero
* elements. When multiple elements are provided, It is also an error if
* none of them has a name property. Otherwise, those with no name property are
- * silently ignored and the ones with a name property are exposed.
- *
- * NB Params
+ *
+ *
+ *
+ *
*
- * element naming
+ * Element Naming
*
- * If an element contains a property named name, then the value of this property
+ *
*
* Element Views
*
- * The parameter API allows a developer to choose the structural model imposed on
+ *
*
*
- *
@@ -49,37 +50,44 @@ import java.util.stream.Collectors;
* view
as singleview
as multiple
* source is
multiple elementsusing element name.param name iterable
elementssingle element view
+ *
*
- * The one element access interface is mean to provide basic support for
+ * This decision is made by which access method below is used. It is key that the
+ * format of the provided data and the interpretation are in alignment. To ensure that
+ * the consumer side of this API uses the configuration data appropriately, make
+ * sure that users are well informed on valid formats. Basically, write good
+ * docs and provide good examples in them.
+ *
+ *
+ * Single-Element View
+ *
+ *
+ *
+ * element list view
- *
- * When accessing some elements, any number of elements may be provided, even zero.
- *
+ * silently ignored and the ones with a name property are exposed.
When accessing some elements, any number of elements may be provided, even zero.
+ *A parameter can be read from a reader by simple name or by a hierarchic name. + * hierarchic names are simply simple names concatenated by a dot '.'.
*/ public class NBParams { diff --git a/nb-api/src/test/java/io/nosqlbench/nb/api/config/params/NBParamsTest.java b/nb-api/src/test/java/io/nosqlbench/nb/api/config/params/NBParamsTest.java index 5aadf28f2..250d39695 100644 --- a/nb-api/src/test/java/io/nosqlbench/nb/api/config/params/NBParamsTest.java +++ b/nb-api/src/test/java/io/nosqlbench/nb/api/config/params/NBParamsTest.java @@ -1,7 +1,6 @@ package io.nosqlbench.nb.api.config.params; -import org.junit.jupiter.api.Disabled; import org.junit.jupiter.api.Test; import java.util.Date; @@ -36,9 +35,10 @@ public class NBParamsTest { } @Test - @Disabled("This case is unwieldy and generally not useful") + // Fixed this. Agreed it is is generally unwieldy and unuseful as an example although it does test the underlying resolver mechanisms public void testNestedMixedJsonParamsMap() { - Element one = NBParams.one("{\"key1\":\"key2={\"key3\":\"value3\",\"key4\":\"value4\"}\"}"); + String source = "{\"key1\":\"key2={\\\"key3\\\":\\\"value3\\\",\\\"key4\\\":\\\"value4\\\"}\"}"; + Element one = NBParams.one(source); assertThat(one.get("key1.key2.key3", String.class)).isPresent(); assertThat(one.get("key1.key2.key3", String.class).get()).isEqualTo("value3"); assertThat(one.get("key1.key2.key4", String.class).get()).isEqualTo("value4");