You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tinkerpop.apache.org by "stephen mallette (JIRA)" <ji...@apache.org> on 2019/05/20 13:13:00 UTC

[jira] [Closed] (TINKERPOP-2216) Consider adding conventional status attribute key for warnings

     [ https://issues.apache.org/jira/browse/TINKERPOP-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

stephen mallette closed TINKERPOP-2216.
---------------------------------------
       Resolution: Done
         Assignee: stephen mallette
    Fix Version/s: 3.4.2

> 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
>            Assignee: stephen mallette
>            Priority: Minor
>             Fix For: 3.4.2
>
>
> [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)