Aklakan commented on code in PR #3441:
URL: https://github.com/apache/jena/pull/3441#discussion_r2386339028
##########
jena-rdfconnection/src/main/java/org/apache/jena/rdflink/RDFLinkHTTP.java:
##########
@@ -221,163 +220,54 @@ public Graph queryDescribe(String queryString) {
public boolean queryAsk(String queryString) {
return
Txn.calculateRead(this, ()->{
- try ( QueryExec qExec = query(queryString, QueryType.ASK) ) {
+ try ( QueryExec qExec = query(queryString) ) {
return qExec.ask();
}
} );
}
- /**
Review Comment:
> The QueryType may not be particularly useful in this impl
The main reason is that I though that `QueryExecBuilder` should be the
single point of truth, and logic outside of it should be avoided:
Having query type handling here seems to add needless complexity because
these methods are mostly shortcuts to `QueryExecBuilder` (plus transaction
wrapping). `QueryExecBuilder` does not have an API to which the query type can
be passed, and in these specific cases, the `QueryExec` created by the
`QueryExecBuilder` attempts to execute the string with a certain query type
just one line below - so it felt redundant.
Of course, if you prefer I can restore this. Alternatively,
`QueryExecBuilder` could receive query(queryString, queryType) method variants
- but again the use might be limited. It would allow for `QueryExec` to check
whether a called exec method, such as ask(), is consistent with the set query
type prior to actually sending an e.g. remote request. But one would then
always have to supply query strings with query types and in case of an
inconsistency, there would be an eventual failure anyway.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]