Details
-
Type:
Bug
-
Status: Done
-
Priority:
Highest
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: BLAZEGRAPH_RELEASE_1_5_2
-
Component/s: Bigdata SAIL, RemoteRepository
-
Labels:None
Description
prepare*Query methods from BigdataSailRemoteRepositoryConnection return query objects that support only evaluate() method, other methods throw UnsupportedOperationException. There are TODOs about implementing that:
* TODO Implement buffering of adds and removes so that we can turn off * auto-commit. * TODO Fix all the Query objects (TupleQuery, GraphQuery, * BooleanQuery) to support the various possible operations on them, such as * setting a binding.
I found this when I tried to use evaluate(RDFHandler/TupleQueryResultHandler) and setBinding() methods.
Why I need them:
- setBinding() is just convenient to use
- e.g. you don't have to worry about escaping while manually constructing bindings in SPARQL. And our exising code uses this method a lot.
- evaluate() with callback can be more efficient because it can avoid using additional thread from executor to parse result and use calling thread to do that at the same time handling the results.
Also we will probably need setMaxQueryTime().
This is about READ_CACHE branch rev 7217.
Issue Links
- relates to
-
BLZG-1099
BigdataSailUpdate.execute() commits the connection
- Open
-
BLZG-1225
Support begin(), prepare(), isActive() in BigdataSailConnection
-
- In Progress
-
-
BLZG-753
Result of BigdataSailRemoteRepositoryConnection.getStatements() and export() do not preserve statement context.
-
- Done
-
-
BLZG-1210
Optimize hasStatement()
-
- Open
-
-
BLZG-1266
Create stress test for REST API with coverage of all methods and abort code paths.
-
- In Progress
-
-
BLZG-1619
Support Sesame2 repository queries Timeout parameter
-
- Done
-
Activity
Modified the logic to determine the query timeout to test for >= 0 rather than != -1
CI is green on REMOTE_INTERFACE_METHODS after merging in master.
I have merged REMOTE_INTERFACE_METHODS back to master.
Note: BLZG-789 is still in progress (test cases are being written) but we are ready for QA on the 1.5.2 release.
@igorkim please make sure that the new tests are in a new branch. You can branch from the current master. It has everything from REMOTE_INTERFACE_METHODS.
Igor, what is the status on the expanded test suite for the new REST API interface methods? Can this ticket be closed yet?
I've updated client-side tests com.bigdata.rdf.sail.remote.BigdataSailRemoteRepositoryConnectionTest
and added server-side test suite com.bigdata.rdf.sail.webapp.Test_Ticket_789.
Note that com.bigdata.rdf.sail.webapp.client.AbstractConnectOptions.getRequestParam(String) returns only first value for the specified name, thus only one default graph and only one named graph could be tested.
The requestParams map is public. You can directly resolve all values. The helper method is there to get just the first one.
/**
* Request parameters to be formatted as URL query parameters.
*/
public Map<String, String[]> requestParams;
BLZG-791specifically requested the ability to use the setMaxQueryTime() method for the prepared query. That issue can be dealt with as part of this ticket.bigdata internally supports millisecond resolution deadlines and that support could be exposed as a query hint. The setMaxQueryTime() only supports second resolution. Since the target deadlines are on the order of 300ms, a one second deadline would be too slow.
There has also been some discussion about query groups and thread pools that needs to be resolved before we move further with implementing the missing methods on this API as those methods might not actually satisfy the application requirements for HA (e.g., having both low-latency and high-latency thread pools and being able to cancel a group of related queries when a deadline expires).