[
https://issues.apache.org/jira/browse/TINKERPOP-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16843954#comment-16843954
]
ASF GitHub Bot commented on TINKERPOP-2216:
-------------------------------------------
spmallette commented on pull request #1113: TINKERPOP-2216 add status attribute
for warnings
URL: https://github.com/apache/tinkerpop/pull/1113
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
> Consider adding conventional status attribute key for warnings
> --------------------------------------------------------------
>
> Key: TINKERPOP-2216
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2216
> Project: TinkerPop
> Issue Type: Improvement
> Components: console, server
> Affects Versions: 3.4.2
> Reporter: Dan LaRocque
> Priority: Minor
>
> [Status
> attributes|http://tinkerpop.apache.org/docs/3.4.1/upgrade/#_status_attributes]
> let server-side graph providers send arbitrary metadata alongside graph
> resultsets. The client can either ignore attributes or check for them.
> A remote graph implementation might want to send warning information back to
> the client along with a resultset. Maybe a traversal executed successfully,
> but it contained some kind of implementation-specific antipattern that
> justifies a warning.
> For instance, {{Tokens}} defines {{STATUS_ATTRIBUTE_EXCEPTIONS}} and
> {{STATUS_ATTRIBUTE_STACK_TRACE}}. Perhaps we could add a new
> {{STATUS_ATTRIBUTE_WARNINGS}} alongside those two. The console's
> {{DriverRemoteAcceptor}} could check for this key when processing each result
> set, printing the associated value (when an entry is present).
> I've already done this on the 3.4.x line. I don't know whether this is
> something TinkerPop would want, or whether it should remain in
> vendor-specific extensions, or if there is some other approach that might fit
> better; but I'll open a PR with what I've been using.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
