QueryOptionsManager readOptions method throw 400 Bad Request response.

[georgeajit]

QueryOptionsManager readOptions URL endpoint seems to be incorrect when REST layer is reached. The queryoptions are persistent on the REST Server.

Sample code snippet is

          // create query options handle
    QueryOptionsHandle handle = new QueryOptionsHandle();

    // build query options
    handle.withConfiguration(builder.configure()
            .returnMetrics(false)
            .returnQtext(false))
            .withTransformResults(builder.rawResults())
            .withSortOrders(builder.sortByScore(Direction.DESCENDING), builder.sortOrder(builder.elementRangeIndex(new QName("http://purl.org/dc/elements/1.1/", "date"), builder.rangeType("xs:date")), Direction.ASCENDING));

    // write query options
    optionsMgr.writeOptions("SortOrderPrimaryDescScoreSecondaryAscDate", handle);

    // read query option
    StringHandle readHandle = new StringHandle();
    readHandle.setFormat(Format.JSON);
    optionsMgr.readOptions("SortOrderPrimaryDescScoreSecondaryAscDate", readHandle);

Wire trace when readOptions is debugged:

Sending request: GET /v1/config/query/SortOrderPrimaryDescScoreSecondaryAscDate?database=TestQueryOptionBuilderSortOrderDB HTTP/1.1
2015/08/20 10:11:09:777 PDT [DEBUG] DefaultClientConnection - Receiving response: HTTP/1.1 400 Bad Request

The configuration specs says /v1/config/query

End user exception message back to the Java Client is
Local message: /config/query read failed: Bad Request. Server Message: REST-UNSUPPORTEDPARAM: (rest:UNSUPPORTEDPARAM) Endpoint does not support query parameter: database

Here is the stack trace
com.marklogic.client.FailedRequestException: Local message: /config/query read failed: Bad Request. Server Message: REST-UNSUPPORTEDPARAM: (rest:UNSUPPORTEDPARAM) Endpoint does not support query parameter: database
at com.marklogic.client.impl.JerseyServices.getValue(JerseyServices.java:2730)
at com.marklogic.client.impl.QueryOptionsManagerImpl.readOptions(QueryOptionsManagerImpl.java:98)
at com.marklogic.client.functionaltest.TestQueryOptionBuilderSortOrder.testSortOrderDescendingScore(TestQueryOptionBuilderSortOrder.java:117)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192)

[sammefford]

Since options are always stored in the modules database for the rest server associated with the port we're accessing, this is one scenario where it does not make sense for us to provide an alternative database name. Can we remove the alternative database name for this test?

[grechaw]

No, I think the semantics is just different than you're thinking -- and the test may be wrong.

If you use the database parameter, it should change the content database of the request, but the modules database remains the one associated with the appserver/port you're accessing.

So for this endpoint, you're right that the database parameter doesn't affect where the options are stored or retrieved from. So at the very least the database parameter should be a noop.

[sammefford]

I chatted with Charles and we're in agreement that this test can go away. Unless you want to convert it into a negative test which validates that we do throw an error when this API is used incorrectly this way.

[georgeajit]

The tests changed to expect exceptions.