-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EI-2742 - Introduce updated SparqlQuery RPC (for FKG) #36
Conversation
proto/iotics/api/meta.proto
Outdated
@@ -82,29 +80,6 @@ enum SparqlResultType { | |||
RDF_NTRIPLES = 5; | |||
} | |||
|
|||
// SparqlQueryRequest describes a SPARQL query. | |||
message SparqlQueryRequest { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note to reviewers: This is not re-used/modified since ExplorerQuery
still uses it.
proto/iotics/api/meta.proto
Outdated
// belongs. The result is returned as a sequence of chunks. Note that: | ||
// - Result chunks MIGHT arrive out of order and it is the client's responsibility to re-assemble them. | ||
// - This RPC is currently in alpha! | ||
rpc FKGQuery(FKGQueryRequest) returns (stream FKGQueryResponse) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do think of just keeping the SparqlQuery
naming?
Seems like FKGQuery
just muddies the water.
The doc string can indicate the enhanced abilities, but its still just sending a sparql query?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure - I hadn't realised we were happy with keeping exactly the same name 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
proto/iotics/api/meta.proto
Outdated
// belongs. The result is returned as a sequence of chunks. Note that: | ||
// - Result chunks MIGHT arrive out of order and it is the client's responsibility to re-assemble them. | ||
// - This RPC is currently in alpha! | ||
rpc FKGQuery(FKGQueryRequest) returns (stream FKGQueryResponse) {} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need the FKG prefix in all the items?
Can't we assume this is "the" only API we'll ever need?
If we need specialisations, then the name of the specialisation can be added
Also does Query imply only the ability to read only?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Query is read-only (just like before SparqlQuery & SparqlUpdate) - but see above - I'll change it back to SparqlQuery
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
24d01b6
(Note that I'll change the commit message at the end. Probably easier to look at the whole diff rather than my fixup)
rpc SparqlQuery(SparqlQueryRequest) returns (stream SparqlQueryResponse) {} | ||
// FKGQuery performs a SPARQL 1.1 query against the Federated Knowledge Graph of the Iotics network to which this host | ||
// belongs. The result is returned as a sequence of chunks. Note that: | ||
// - Result chunks MIGHT arrive out of order and it is the client's responsibility to re-assemble them. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why the out of order?
it all chunks are guaranteed to be produced, why can't they be reordered by the server?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because we don't really want to buffer an arbitrary amount of data, in memory, on the server
proto/iotics/api/meta.proto
Outdated
Scope scope = 2; | ||
|
||
// SPARQL query request payload | ||
Payload payload = 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we need the payload?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes we need it to be consistent with everything else in the API
proto/iotics/api/meta.proto
Outdated
|
||
// The desired result content type. Note that choosing an invalid result type for the type of query will result in | ||
// an error status reported in the response. (See SparqlResultType for valid content-query type combinations.) | ||
SparqlResultType resultContentType = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you document the behaviour if resultContentType isn't specified
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure - I'll add the default
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
24d01b6 (basically it'll be the default enum value since the field cannot be "empty")
proto/iotics/api/meta.proto
Outdated
bool last = 2; | ||
|
||
// Content type of the result. | ||
SparqlResultType contentType = 3; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do you need this? or will it be == to the valye in the request
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it will be equal.
This is so that the receiver of responses doesn't need to know about the request necessarily. (We have the same approach in the original SparqlQuery and other fields such as - headers with client references)
proto/iotics/api/meta.proto
Outdated
|
||
// Query result chunk, encoded according to actualType. | ||
// Note that: | ||
// - The maximum size of each chunk is host-specific. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how does one find what the value is?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is no way yet but we could (later) expose a host high-level conf page. It could be part of an admin API, etc. For now it is visible via the AWS console
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK - so it should be possible to document the current value here in the API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could hint at a default but I think "hard coding" it here in the docs means we cannot change it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Local-scope SparqlQuery will be removed in the end |
It looks good in principle. It is consistent with what we have in the API in general and the chunking approach is consistent with what we were doing for Sparql query (minus the multi-host reply). I would vote for a more generic name like "SparqlQuery". |
If you mean the old SparqlQuery+local will be replaced - sure. |
This just means the existing SparqlQuery will be removed. |
message Payload { | ||
|
||
// Position of a chunk in result for a given request. The first chunk has a sequence number of 0. | ||
uint64 seqNum = 1; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question (CC @StephanieBracaloni ): Do we want to keep this compatible in terms of field indexes by starting with 2
here? (hostId
was 1 before)?
That way existing SPARQL requests made should still work and hostId
would be ignored.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The field indexes do not matter (ie. it is ok if it starts from 2).
However, we don't want to/don't have to keep things compatible since we have announced a breaking change (even if only internal since sparql query is not used publicly yet) and the response format will also break the compatibility.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The field indexes do not matter
the response format will also break the compatibility
.. this is the only difference? (I don't understand what you mean but never mind.)
Anyway - if we're OK to break - let's keep start at index 1
, as you would if it were brand new 👍
- Local-scope SparqlQuery can be performed with FKGQuery local-scope
Local-scope SparqlQuery can be performed with FKGQuery local-scopeSame as before now