marklogic/java-client-api

Optic enhancements in 10.0-7

ehennum opened this issue · 3 comments

Enhancements:

1. RowManager generateView() and generateViewAs() methods similar to the existing explain() and explainAs() methods

https://docs.marklogic.com/javadoc/client/com/marklogic/client/row/RowManager.html#explain-com.marklogic.client.expression.PlanBuilder.Plan-T-

The signatures:

<T extends XMLReadHandle> T generateView​(PlanBuilder.Plan plan, String schema, String view, T handle)

<T> T generateView​As(PlanBuilder.Plan plan, String schema, String view, java.lang.Class<T> as)

The HTTP request sets the schemaName and viewName request parameters and sets the output request parameter to "generateView" instead of "explain"

2. ModifyPlan existsJoin() and notExistsJoin() methods similar to the existing joinInner() method; bind() similar to the existing select() method.

Given that code generation takes care of the joinInner() interface and implementation, code generation should be able to take care of the syntactically identical existsJoin() and notExistsJoin() methods.

This bug identifies the methods for completeness.

3. The methods supporting "Redaction On Rows" (see the internal wiki page)

The methods names: maskDeterministic(), maskRandom(), redactDatetime(), redactEmail(), redactIpv4(), redactNumber(), redactRegex(), redactUsSsn(), and redactUsPhone().

Each method has the same signature. For example:

PlanExprCol maskDeterministic​(PlanColumn column, Map<String,String> options)

A new expression.RdtExpr interface declares the methods.

A new impl.RdtExprImpl class implements the methods, serializing the inputs similar to

https://github.com/marklogic/java-client-api/blob/master/marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java#L321-L324

but taking a Map<String,String> instead of a ServerExpression and serializing the map in the same way as:

https://github.com/marklogic/java-client-api/blob/master/marklogic-client-api/src/main/java/com/marklogic/client/impl/PlanBuilderSubImpl.java#L503

It should be possible for all of the redaction methods to share an implementation by passing in the function name, column, and options to a private method.

The code generation for PlanBuilder will need to implement a new field:

public final RdtExpr rdt;

PlanBuilderBaseImpl will need to initialize the new field with RdtExprImpl.rdt

@llinggit, item 2 should be taken care of by this commit, though the documentation on bind() will need to be updated later.

Given that the functionality is tested for the server distribution, the client coverage only needs to verify that inputs and outputs
are transported correctly.

Please take a look at the unit tests and consider whether they are sufficient for coverage of transport.

This issue contains server-side changes.