[jira] [Commented] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
[ https://issues.apache.org/jira/browse/TINKERPOP-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16479582#comment-16479582 ] Ashwini Singh commented on TINKERPOP-1913: -- Hi I am not an expert on javascript and python. Can owners of python and javascript take this up. Thanks Ashwini > Expose metadata from Gremlin Server to Clients > -- > > Key: TINKERPOP-1913 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, javascript, python, server >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Assignee: stephen mallette >Priority: Major > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response attribute as > part of result. Using an approach to similar to Java client driver (using > ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority 0] > --Rely on the last message for attributes. > 3. Expose other server details (like server setting). I would suggest to > split this design discussion into two directions: > a. Metadata for request execution: Only focuses on details > related to request execution. Can be achieved through #1 and #2. > b. Metadata for Gremlin Server: Focuses on overall metadata > for the server. Could be a separate request and fetch the data once for a > connection. > Targeted drivers: dotnet, Java, python, javascript. > More details: > [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
[ https://issues.apache.org/jira/browse/TINKERPOP-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419789#comment-16419789 ] Ashwini Singh commented on TINKERPOP-1913: -- Hey Stephen, Have we created a branch with the initial change on the server side to produce the attributes (as per discussed on the mail thread). If you can create that branch, I can chip in for some of the drivers side change. Thanks Ashwini > Expose metadata from Gremlin Server to Clients > -- > > Key: TINKERPOP-1913 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, driver, javascript, python, server >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Assignee: stephen mallette >Priority: Major > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response attribute as > part of result. Using an approach to similar to Java client driver (using > ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority 0] > --Rely on the last message for attributes. > 3. Expose other server details (like server setting). I would suggest to > split this design discussion into two directions: > a. Metadata for request execution: Only focuses on details > related to request execution. Can be achieved through #1 and #2. > b. Metadata for Gremlin Server: Focuses on overall metadata > for the server. Could be a separate request and fetch the data once for a > connection. > Targeted drivers: dotnet, Java, python, javascript. > More details: > [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: Gremlin Go Driver
Thanks Stephen. Go-gremlin have got a maintainer recently. https://github.com/go-gremlin/gremlin/issues/8 Also , looks more mature with authentication support. Ashwini -Original Message- From: Stephen Mallette <spmalle...@gmail.com> Sent: Monday, March 26, 2018 1:13 PM To: dev@tinkerpop.apache.org Cc: Luis Bosquez Gonzalez <lb...@microsoft.com>; Siddhesh Vethe <siddhesh.ve...@microsoft.com> Subject: Re: Gremlin Go Driver go-gremlin was first on the scene if i remember correctly, but i think the maintainer had to pull away from it. then gremgo came out later, which i think is the one most folks reach for as it is more actively maintained and better featured (just my impression from anecdotes) . i believe there is a third one under development as well, but i can't find the link atm. i'd say Go is probably the next most requested language for a Gremlin GLV now that we have javascript. On Mon, Mar 26, 2018 at 4:01 PM, Ashwini Singh < ashws...@microsoft.com.invalid> wrote: > Hi Guys, > > There are two Go drivers for gremlin projects are going on Github, > go-gremlin and gremgo. > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > b.com%2Fgo-gremlin%2Fgremlin%2Fissues%2F8=02%7C01%7Cashwsing%40mi > crosoft.com%7Cf5873d4ba8ac4154ca7708d5935605f9%7C72f988bf86f141af91ab2 > d7cd011db47%7C1%7C0%7C636576920058283494=h9bJ%2BgWKZ3fIX3QJx3Fm1 > hr8UT91B2TVY27BmaMPpAc%3D=0 > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithu > b.com%2Fqasaur%2Fgremgo=02%7C01%7Cashwsing%40microsoft.com%7Cf587 > 3d4ba8ac4154ca7708d5935605f9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C > 0%7C636576920058293498=U%2FH6NWeSj4SmtaGhXDXzLgo2RJ3grCiKJcRdWbp > i8XM%3D=0 > > Is there any preference in the community which on to use? > > Thanks > Ashwini Singh > Software Engineer @Microsoft Azure CosmosDB > > > > >
Gremlin Go Driver
Hi Guys, There are two Go drivers for gremlin projects are going on Github, go-gremlin and gremgo. https://github.com/go-gremlin/gremlin/issues/8 https://github.com/qasaur/gremgo Is there any preference in the community which on to use? Thanks Ashwini Singh Software Engineer @Microsoft Azure CosmosDB
[jira] [Commented] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
[ https://issues.apache.org/jira/browse/TINKERPOP-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16410530#comment-16410530 ] Ashwini Singh commented on TINKERPOP-1909: -- Thanks for detail discussion. This is really helpful to understand TinkerPop design and the future direction.Based on the discussed in this thread , I have submitted the design doc to support ref based object model along with full object model for GraphSON. PR : [https://github.com/apache/tinkerpop/pull/824] > Gremlin.Net does not have complete object model as compared to other client > drivers and unable to de-serialize properties for vertex/edge graphSON. > - > > Key: TINKERPOP-1909 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1909 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > Looks like the object model for Gremlin.Net client driver is not as par with > Java driver. We cannot deserialize a GraphSON response to tinkerpop object > completely. For example, Gremlin.Net object model cannot deserialize > properties from a graphSON response object (vertex/edges). Currently, we only > deserialize id and label field from a vertex/edge graphSON. > > So, to desterilize the object model, users have to write a custom > deserialization code and create the object. The current de-serializers (for > vertex/edge) will strip off details like properties. > > I am filing it as a bug but it could fall into improvement as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1910) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
[ https://issues.apache.org/jira/browse/TINKERPOP-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16408621#comment-16408621 ] Ashwini Singh commented on TINKERPOP-1910: -- My bad. Thanks > Gremlin.Net does not have complete object model as compared to other client > drivers and unable to de-serialize properties for vertex/edge graphSON. > - > > Key: TINKERPOP-1910 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1910 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > Looks like the object model for Gremlin.Net client driver is not as par with > Java driver. We cannot deserialize a GraphSON response to tinkerpop object > completely. For example, Gremlin.Net object model cannot deserialize > properties from a graphSON response object (vertex/edges). Currently, we only > deserialize id and label field from a vertex/edge graphSON. > > So, to desterilize the object model, users have to write a custom > deserialization code and create the object. The current de-serializers (for > vertex/edge) will strip off details like properties. > > I am filing it as a bug but it could fall into improvement as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1928) Gremlin .Net driver not able produce partial results.
[ https://issues.apache.org/jira/browse/TINKERPOP-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwini Singh updated TINKERPOP-1928: - Summary: Gremlin .Net driver not able produce partial results. (was: Gremlin .Net drivers not able parse partial results.) > Gremlin .Net driver not able produce partial results. > -- > > Key: TINKERPOP-1928 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1928 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet > Reporter: Ashwini Singh >Priority: Major > > Gremlin.Net accumulates partial results and returns consolidated result. Java > driver does have the capability to stream partial result. > > We should try to achieve consistent behavior for other drivers like python, > nodejs etc as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-1928) Gremlin .Net drivers not able parse partial results.
Ashwini Singh created TINKERPOP-1928: Summary: Gremlin .Net drivers not able parse partial results. Key: TINKERPOP-1928 URL: https://issues.apache.org/jira/browse/TINKERPOP-1928 Project: TinkerPop Issue Type: Improvement Components: dotnet Reporter: Ashwini Singh Gremlin.Net accumulates partial results and returns consolidated result. Java driver does have the capability to stream partial result. We should try to achieve consistent behavior for other drivers like python, nodejs etc as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
[ https://issues.apache.org/jira/browse/TINKERPOP-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16390072#comment-16390072 ] Ashwini Singh commented on TINKERPOP-1909: -- Yes, agree to keep this discussion only for 3.X Extending the object model+ de-serialiser could be a temporary solution that we have suggested to some of our clients or provided change ourselves. But, its not a scalable solution for long term. So , we would prefer to the Java and dotnet(+other drivers) to adhere to the same object model for version 3.X. [We can definitely move to new model going forward to TinkerPop4+]. And, to me it makes sense to keep all the drivers aligned to same model in the same major version. Can we scope this fix only for 3.X client drivers, what do you think? > Gremlin.Net does not have complete object model as compared to other client > drivers and unable to de-serialize properties for vertex/edge graphSON. > - > > Key: TINKERPOP-1909 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1909 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > Looks like the object model for Gremlin.Net client driver is not as par with > Java driver. We cannot deserialize a GraphSON response to tinkerpop object > completely. For example, Gremlin.Net object model cannot deserialize > properties from a graphSON response object (vertex/edges). Currently, we only > deserialize id and label field from a vertex/edge graphSON. > > So, to desterilize the object model, users have to write a custom > deserialization code and create the object. The current de-serializers (for > vertex/edge) will strip off details like properties. > > I am filing it as a bug but it could fall into improvement as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [Discuss] Expose metadata from Gremlin Server to Clients.
Create a incident: https://issues.apache.org/jira/browse/TINKERPOP-1913 For this, I am fine with that. Lets take this as part of above work item. For #3, Do we need to take this in this work item as well ? Can someone setup the branch? And we can take it from there. Thanks a lot guys, Ashwini Singh Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 From: Stephen Mallette<mailto:spmalle...@gmail.com> Sent: Tuesday, March 6, 2018 3:53 AM To: dev@tinkerpop.apache.org<mailto:dev@tinkerpop.apache.org> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients. Your summary looks good to me. I also agree that we can omit 3b from this body of work. Going back to an earlier question that you had: > Can we spilt the change to support for gremlin request/script first and bytecode/traversal separately? I'm a bit concerned that if we don't at least have the design of the bytecode/traversal piece thought through fully we might not get the client side changes right to support it. Perhaps we see how things go on implementation before making a final decision here, but as of right now, I tend to feel like we shouldn't split this up. To just get started, I think I'd like to get the initial development branch setup with Gremlin Server returning some metadata. That part is pretty easy. Once that branch is setup, anyone contributing can just submit PRs against that or just commit directly to it. Then we can have one PR to evaluate through the review process for this feature I guess there is some question as to what version this body of work should go to. I think I'd like to skip adding this to 3.2.8 and target 3.3.2 on the tp33 branch. At this point, I think 3.2.x should really just contain bug fixes and minor enhancements - I don't think this particular enhancement qualifies as "minor". Ashwini, if all that sounds good, could you please create a JIRA ticket that contains a final summary and references this thread? On Mon, Mar 5, 2018 at 2:47 PM, Ashwini Singh < ashws...@microsoft.com.invalid> wrote: > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response > attribute as part of result. Using an approach to similar to Java client > driver (using ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority > 0] > --Rely on the last message for attributes. > 3. Expose other server details (like server setting). I would > suggest to split this design discussion into two directions: > a. Metadata for request execution: Only focuses on details > related to request execution. Can be achieved through #1 and #2. > b. Metadata for Gremlin Server: Focuses on overall > metadata for the server. Could be a separate request and fetch the data > once for a connection. Any other suggestion ? > > Please add if I am missing something. > > Thanks a lot, > Ashwini Singh > Software Engineer @ Azure Cosmos DB > > -Original Message- > From: Stephen Mallette <spmalle...@gmail.com> > Sent: Friday, March 2, 2018 4:49 AM > To: dev@tinkerpop.apache.org > Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients. > > Perhaps another useful piece of data to return from Gremlin Server: > > https://na01.safelinks.protection.outlook.com/?url= > https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse% > 2FTINKERPOP-1636=04%7C01%7Cashwsing%40microsoft.com% > 7C621c0a838bd24f13eb4e08d5803bed5d%7C72f988bf86f141af91ab2d7cd011 > db47%7C1%7C0%7C636555917242398527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw > MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1= > bVd71RV9uDiWWgsjY7SYAIYEhWtLdi7Ijgv9um%2F1JoM%3D=0 > > On Thu, Mar 1, 2018 at 6:31 PM, Stephen Mallette <spmalle...@gmail.com> > wrote: > > > I just came across this: > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissue > > s.apache.org%2Fjira%2Fbrowse%2FTINKERPOP-1494=04%7C01%7Cashwsing% > > 40microsoft.com%7C621c0a838bd24f13eb4e08d5803bed5d%7C72f988bf86f141af9 > > 1ab2d7cd011db47%7C1%7C0%7C636555917242398527%7CUnknown%7CTWFpbGZsb3d8e > > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1 > > =1kY8r73w2Y3euQVnLEGIuAO0fX6ZySOzl%2BVUgbhodpE%3D=0 > > > > There's some ideas for what the open source Gremlin Server could > > return therefor example, perhaps we send back the the host that > > executed the script as the metadata for Gremlin Server? > > > > On Wed, Feb 28, 2018 at 5:37 PM, Ashwini Singh <ashws...@microsoft.com. > > invalid> wrote: > > > >> > >> Completely agree on making
[jira] [Updated] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
[ https://issues.apache.org/jira/browse/TINKERPOP-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwini Singh updated TINKERPOP-1913: - Description: To summarize what we have discussed so far: 1. For API using GremlinRequest/QueryScript, expose response attribute as part of result. Using an approach to similar to Java client driver (using ResultSet) . [Priority0] -- We rely on the last message for response attributes. 2. For GLV, add response attribute as part of Traversal. [Priority 0] --Rely on the last message for attributes. 3. Expose other server details (like server setting). I would suggest to split this design discussion into two directions: a. Metadata for request execution: Only focuses on details related to request execution. Can be achieved through #1 and #2. b. Metadata for Gremlin Server: Focuses on overall metadata for the server. Could be a separate request and fetch the data once for a connection. Targeted drivers: dotnet, Java, python, javascript. More details: [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] was: To summarize what we have discussed so far: 1. For API using GremlinRequest/QueryScript, expose response attribute as part of result. Using an approach to similar to Java client driver (using ResultSet) . [Priority0] -- We rely on the last message for response attributes. 2. For GLV, add response attribute as part of Traversal. [Priority 0] --Rely on the last message for attributes. More details: [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > Expose metadata from Gremlin Server to Clients > -- > > Key: TINKERPOP-1913 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response attribute as > part of result. Using an approach to similar to Java client driver (using > ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority 0] > --Rely on the last message for attributes. > 3. Expose other server details (like server setting). I would suggest to > split this design discussion into two directions: > a. Metadata for request execution: Only focuses on details > related to request execution. Can be achieved through #1 and #2. > b. Metadata for Gremlin Server: Focuses on overall metadata > for the server. Could be a separate request and fetch the data once for a > connection. > Targeted drivers: dotnet, Java, python, javascript. > More details: > [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
[ https://issues.apache.org/jira/browse/TINKERPOP-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwini Singh updated TINKERPOP-1913: - Affects Version/s: 3.3.1 > Expose metadata from Gremlin Server to Clients > -- > > Key: TINKERPOP-1913 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response attribute as > part of result. Using an approach to similar to Java client driver (using > ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority 0] > --Rely on the last message for attributes. > > More details: > [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
[ https://issues.apache.org/jira/browse/TINKERPOP-1913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ashwini Singh updated TINKERPOP-1913: - Description: To summarize what we have discussed so far: 1. For API using GremlinRequest/QueryScript, expose response attribute as part of result. Using an approach to similar to Java client driver (using ResultSet) . [Priority0] -- We rely on the last message for response attributes. 2. For GLV, add response attribute as part of Traversal. [Priority 0] --Rely on the last message for attributes. More details: [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] was: To summarize what we have discussed so far: 1. For API using GremlinRequest/QueryScript, expose response attribute as part of result. Using an approach to similar to Java client driver (using ResultSet) . [Priority0] -- We rely on the last message for response attributes. 2.For GLV, add response attribute as part of Traversal. [Priority 0] --Rely on the last message for attributes. > Expose metadata from Gremlin Server to Clients > -- > > Key: TINKERPOP-1913 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 > Project: TinkerPop > Issue Type: Improvement > Reporter: Ashwini Singh >Priority: Major > > To summarize what we have discussed so far: > 1. For API using GremlinRequest/QueryScript, expose response attribute as > part of result. Using an approach to similar to Java client driver (using > ResultSet) . [Priority0] > -- We rely on the last message for response attributes. > 2. For GLV, add response attribute as part of Traversal. [Priority 0] > --Rely on the last message for attributes. > > More details: > [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-1913) Expose metadata from Gremlin Server to Clients
Ashwini Singh created TINKERPOP-1913: Summary: Expose metadata from Gremlin Server to Clients Key: TINKERPOP-1913 URL: https://issues.apache.org/jira/browse/TINKERPOP-1913 Project: TinkerPop Issue Type: Improvement Reporter: Ashwini Singh To summarize what we have discussed so far: 1. For API using GremlinRequest/QueryScript, expose response attribute as part of result. Using an approach to similar to Java client driver (using ResultSet) . [Priority0] -- We rely on the last message for response attributes. 2.For GLV, add response attribute as part of Traversal. [Priority 0] --Rely on the last message for attributes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
[ https://issues.apache.org/jira/browse/TINKERPOP-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16386779#comment-16386779 ] Ashwini Singh commented on TINKERPOP-1909: -- Few more questions. I understand the future direction for TinkerPop 4.X. But as of now what do you think about filling the gaps between .net and other drivers in TInkerPop3.X for customers who have taken the dependency on the older version? What is our plan for bulk insert story (data insert) on TinkerPop 4.X? For a query, it makes sense to return reference data for different reasons(perf etc.). But, what is our plan for reading data from full graphSON file and insert into the store?, Without the full object model. > Gremlin.Net does not have complete object model as compared to other client > drivers and unable to de-serialize properties for vertex/edge graphSON. > - > > Key: TINKERPOP-1909 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1909 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > Looks like the object model for Gremlin.Net client driver is not as par with > Java driver. We cannot deserialize a GraphSON response to tinkerpop object > completely. For example, Gremlin.Net object model cannot deserialize > properties from a graphSON response object (vertex/edges). Currently, we only > deserialize id and label field from a vertex/edge graphSON. > > So, to desterilize the object model, users have to write a custom > deserialization code and create the object. The current de-serializers (for > vertex/edge) will strip off details like properties. > > I am filing it as a bug but it could fall into improvement as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [Discuss] Expose metadata from Gremlin Server to Clients.
To summarize what we have discussed so far: 1. For API using GremlinRequest/QueryScript, expose response attribute as part of result. Using an approach to similar to Java client driver (using ResultSet) . [Priority0] -- We rely on the last message for response attributes. 2. For GLV, add response attribute as part of Traversal. [Priority 0] --Rely on the last message for attributes. 3. Expose other server details (like server setting). I would suggest to split this design discussion into two directions: a. Metadata for request execution: Only focuses on details related to request execution. Can be achieved through #1 and #2. b. Metadata for Gremlin Server: Focuses on overall metadata for the server. Could be a separate request and fetch the data once for a connection. Any other suggestion ? Please add if I am missing something. Thanks a lot, Ashwini Singh Software Engineer @ Azure Cosmos DB -Original Message- From: Stephen Mallette <spmalle...@gmail.com> Sent: Friday, March 2, 2018 4:49 AM To: dev@tinkerpop.apache.org Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients. Perhaps another useful piece of data to return from Gremlin Server: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FTINKERPOP-1636=04%7C01%7Cashwsing%40microsoft.com%7C621c0a838bd24f13eb4e08d5803bed5d%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636555917242398527%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=bVd71RV9uDiWWgsjY7SYAIYEhWtLdi7Ijgv9um%2F1JoM%3D=0 On Thu, Mar 1, 2018 at 6:31 PM, Stephen Mallette <spmalle...@gmail.com> wrote: > I just came across this: > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissue > s.apache.org%2Fjira%2Fbrowse%2FTINKERPOP-1494=04%7C01%7Cashwsing% > 40microsoft.com%7C621c0a838bd24f13eb4e08d5803bed5d%7C72f988bf86f141af9 > 1ab2d7cd011db47%7C1%7C0%7C636555917242398527%7CUnknown%7CTWFpbGZsb3d8e > yJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1 > =1kY8r73w2Y3euQVnLEGIuAO0fX6ZySOzl%2BVUgbhodpE%3D=0 > > There's some ideas for what the open source Gremlin Server could > return therefor example, perhaps we send back the the host that > executed the script as the metadata for Gremlin Server? > > On Wed, Feb 28, 2018 at 5:37 PM, Ashwini Singh <ashws...@microsoft.com. > invalid> wrote: > >> >> Completely agree on making the change for other drivers too. The plan >> from our side is to make changes to other drivers as well. My focus >> on Gremlin.Net was just for an example . Yes, we should make change >> to Gremlin Server to write the metadata for testing. >> >> I agree to adding this to ResultSet and exposing this as part of >> every response for all the drivers and follow the same pattern as JAVA. >> >> On the gremlin GVL part, I agree we should support this on traversal >> for bytecode as well. For now, we do not have support for bytecode >> but we are actively working on that and need support for metadata there as >> well. >> Thanks for bringing this up. Just wanted to understand how we track >> issues at tinkerpop, Can we spilt the change to support for gremlin >> request/script first and bytecode/traversal separately? If we prefer >> to split the change in chunks, but completely fine with one change. >> >> Thanks, >> Ashwini Singh >> Software Engineer @ Azure Cosmos DB >> >> -Original Message- >> From: Stephen Mallette <spmalle...@gmail.com> >> Sent: Wednesday, February 28, 2018 9:58 AM >> To: dev@tinkerpop.apache.org >> Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients. >> >> This newly created issue might be related to this in some way: >> >> https://na01.safelinks.protection.outlook.com/?url=https%3A% >> 2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FTINKERPOP-1906& >> data=04%7C01%7Cashwsing%40microsoft.com%7C614b32ff7f98 >> 4c66554808d57ed4d22b%7C72f988bf86f141af91ab2d7cd011db47%7C1% >> 7C0%7C636554374885412678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4 >> wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1& >> sdata=w7pyg6JF4KMbPdpBg6t%2F8cE%2BflbnCQQdyMUgc6HDrXw%3D=0 >> >> On Wed, Feb 28, 2018 at 11:37 AM, Florian Hockmann < >> f...@florian-hockmann.de> >> wrote: >> >> > I agree that we also should make this metadata available for >> > traversals since we want to move users away from sending Gremlin >> > scripts as strings and instead use Bytecode based GLVs. >> > >> > Regarding Gremlin.Net: I think that the implement
[jira] [Commented] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
[ https://issues.apache.org/jira/browse/TINKERPOP-1909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16384956#comment-16384956 ] Ashwini Singh commented on TINKERPOP-1909: -- I agree with the direction of gremlin towards being more tidy about data communicated between client and server and we should be wary of the performance problems with always dealing with multi-properties. But, I still think it would be worth consider our ability to de-serialize full vertex/edges if needed.There are few options we can consider for future in TinkerPop 4.x. # Using output format, a Gremlin Server configuration. Output format can be Ref (return id and label) or GraphSONCompact (Ref+ properties) or GraphSON(Ref+properties+ edges). And, Default to Ref. This provides client ability to retrieve more details if required and avoid multiple query. And, fully controlled by the client. # We go ahead with the current ref based object model and let applications extend the object model + deserializers if required. Looks doable for Gremlin.Net at least. What do you think ? > Gremlin.Net does not have complete object model as compared to other client > drivers and unable to de-serialize properties for vertex/edge graphSON. > - > > Key: TINKERPOP-1909 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1909 > Project: TinkerPop > Issue Type: Bug > Components: dotnet >Affects Versions: 3.3.1 > Reporter: Ashwini Singh >Priority: Major > > Looks like the object model for Gremlin.Net client driver is not as par with > Java driver. We cannot deserialize a GraphSON response to tinkerpop object > completely. For example, Gremlin.Net object model cannot deserialize > properties from a graphSON response object (vertex/edges). Currently, we only > deserialize id and label field from a vertex/edge graphSON. > > So, to desterilize the object model, users have to write a custom > deserialization code and create the object. The current de-serializers (for > vertex/edge) will strip off details like properties. > > I am filing it as a bug but it could fall into improvement as well. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-1910) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
Ashwini Singh created TINKERPOP-1910: Summary: Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON. Key: TINKERPOP-1910 URL: https://issues.apache.org/jira/browse/TINKERPOP-1910 Project: TinkerPop Issue Type: Bug Components: dotnet Affects Versions: 3.3.1 Reporter: Ashwini Singh Looks like the object model for Gremlin.Net client driver is not as par with Java driver. We cannot deserialize a GraphSON response to tinkerpop object completely. For example, Gremlin.Net object model cannot deserialize properties from a graphSON response object (vertex/edges). Currently, we only deserialize id and label field from a vertex/edge graphSON. So, to desterilize the object model, users have to write a custom deserialization code and create the object. The current de-serializers (for vertex/edge) will strip off details like properties. I am filing it as a bug but it could fall into improvement as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (TINKERPOP-1909) Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON.
Ashwini Singh created TINKERPOP-1909: Summary: Gremlin.Net does not have complete object model as compared to other client drivers and unable to de-serialize properties for vertex/edge graphSON. Key: TINKERPOP-1909 URL: https://issues.apache.org/jira/browse/TINKERPOP-1909 Project: TinkerPop Issue Type: Bug Components: dotnet Affects Versions: 3.3.1 Reporter: Ashwini Singh Looks like the object model for Gremlin.Net client driver is not as par with Java driver. We cannot deserialize a GraphSON response to tinkerpop object completely. For example, Gremlin.Net object model cannot deserialize properties from a graphSON response object (vertex/edges). Currently, we only deserialize id and label field from a vertex/edge graphSON. So, to desterilize the object model, users have to write a custom deserialization code and create the object. The current de-serializers (for vertex/edge) will strip off details like properties. I am filing it as a bug but it could fall into improvement as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [Discuss] Expose metadata from Gremlin Server to Clients.
Completely agree on making the change for other drivers too. The plan from our side is to make changes to other drivers as well. My focus on Gremlin.Net was just for an example . Yes, we should make change to Gremlin Server to write the metadata for testing. I agree to adding this to ResultSet and exposing this as part of every response for all the drivers and follow the same pattern as JAVA. On the gremlin GVL part, I agree we should support this on traversal for bytecode as well. For now, we do not have support for bytecode but we are actively working on that and need support for metadata there as well. Thanks for bringing this up. Just wanted to understand how we track issues at tinkerpop, Can we spilt the change to support for gremlin request/script first and bytecode/traversal separately? If we prefer to split the change in chunks, but completely fine with one change. Thanks, Ashwini Singh Software Engineer @ Azure Cosmos DB -Original Message- From: Stephen Mallette <spmalle...@gmail.com> Sent: Wednesday, February 28, 2018 9:58 AM To: dev@tinkerpop.apache.org Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients. This newly created issue might be related to this in some way: https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fissues.apache.org%2Fjira%2Fbrowse%2FTINKERPOP-1906=04%7C01%7Cashwsing%40microsoft.com%7C614b32ff7f984c66554808d57ed4d22b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636554374885412678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwifQ%3D%3D%7C-1=w7pyg6JF4KMbPdpBg6t%2F8cE%2BflbnCQQdyMUgc6HDrXw%3D=0 On Wed, Feb 28, 2018 at 11:37 AM, Florian Hockmann <f...@florian-hockmann.de> wrote: > I agree that we also should make this metadata available for > traversals since we want to move users away from sending Gremlin > scripts as strings and instead use Bytecode based GLVs. > > Regarding Gremlin.Net: I think that the implementation would be very > similar to how it can be implemented in the Java driver as we tried to > stay close to the Java driver in general. The only difference is > probably that we currently don't have a ResultSet in Gremlin.Net, but > that's only because I didn't see much value in adding that. Metadata > would of course be a good argument to also implement a ResultSet in > Gremlin.Net and then the implementation should be really basically the > same as in the Java driver. > > > Am 28.02.2018 um 16:15 schrieb Stephen Mallette: > > I'm fine with using the last response message as the carrier for > > this metadata on a particular request. I can't really tell if there > > is much > work > > to do on Gremlin Server itself here. It seems like most of the work > > must occur on the various drivers (you mention the .NET api, but all > > of the drivers would need to support this feature). However, I would > > think that > we > > would want Gremlin Server itself to append in some kind metadata > > (maybe query time? something easy) so that we could write tests > > for the drivers in TinkerPop itself. There is also the question of > > how we would expose this metadata to GLVs which don't see response > > messages at all. A traversal might need some metadata itself so that > > the user could retrieve the server metadata from that. The > > implementation between Java and the > GLVs > > might be different here as the GLV traversal class is typically > > quite lightweight and only used for generating bytecode. > > > > I'm not so sure I like the SubmitAsynWithHeaders() but I don't > > think > too > > much about how the .NET driver works. Is there a reason to not > > always return metadata? could it be expensive to do so? If we just > > added an > extra > > method how would remote traversals configure this option? I think we > > need another way. Generally speaking, for Java, I think I would like > > to see > the > > metadata available to the ResultSet somehow which would in turn make > > it pretty easy to get it on to a Traversal instance once that > > facility was made available.but as to how to enable or disable > > the return of the metadata, i'm not sure how that should work just > > yet - i need to think on that some more. > > > > For committers who work on GLVs, please take a look at this thread > > and offer your thoughts on how this might work in the GLV driver you > > tend to have the most knowledge on. Let's see if we can come to one > > nice unified solution. At that point, we can setup a ticket in JIRA and go > > from there. > > > > Ashwini, thanks for offering a pull request for this by the way. > > Once we get consensus on how
[jira] [Comment Edited] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381019#comment-16381019 ] Ashwini Singh edited comment on TINKERPOP-1906 at 2/28/18 8:47 PM: --- In case of 429, Gremlin Response from Azure Cosmos DB contains ResponseStatusCode.ServerError(500) and exception details as the message, which includes details of 429 exceptions. At the Gremlin.Net driver side, you see the ResponseException because of the error code ResponseStatusCode.ServerError (500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You can check that through tools like Fiddler. I agree with Florian, the change mentioned below is to expose these details and client can handle the rate limiting. [https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] was (Author: ashwini singh): In case of 429, Gremlin Response from Azure Cosmos DB contains ResponseStatusCode.ServerError(500) and exception details as the message, which includes details of 429 exceptions. At the Gremlin.Net driver side, you see the ResponseException because of the error code ResponseStatusCode.ServerError (500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You can check that through tools like Fiddler. I agree with Florian, the change mentioned [here|mailto:%20https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] is to expose these details and client can handle the rate limiting. > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > Attachments: message.txt, stacktrace.txt > > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1906) Make ResponseException explorable
[ https://issues.apache.org/jira/browse/TINKERPOP-1906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381019#comment-16381019 ] Ashwini Singh commented on TINKERPOP-1906: -- In case of 429, Gremlin Response from Azure Cosmos DB contains ResponseStatusCode.ServerError(500) and exception details as the message, which includes details of 429 exceptions. At the Gremlin.Net driver side, you see the ResponseException because of the error code ResponseStatusCode.ServerError (500). Also, Cosmos DB adds more details in the ResponseStatus.Attributes. You can check that through tools like Fiddler. I agree with Florian, the change mentioned [here|mailto:%20https://lists.apache.org/thread.html/fd2208a2db827bc1eb479ad8c2f181bd2fa532553c97b3fe6994a7b6@%3Cdev.tinkerpop.apache.org%3E] is to expose these details and client can handle the rate limiting. > Make ResponseException explorable > - > > Key: TINKERPOP-1906 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1906 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.2.7 >Reporter: Roman Kreisel >Priority: Major > Attachments: message.txt, stacktrace.txt > > > The ResponseException from Gremlin.NET doesn't give you any possibility to > react on the GremlinService's Response. The only content is the exception's > Message, which is just free text. > It would be great, to add some fields to expose at least the HTTP ErrorCode > or anything else that's responded by the service. > > Especially, if you're using Gremlin.NET with Azure's Cosmos DB, there's a > "Request Rate to Large" response, in case you have high load on your > database. In such a case, you want to be able to detect this "error" and just > retry after a few milliseconds (i'm not sure, but i think even a proposal for > this retry-timeout is given in the response) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
RE: [Discuss] Expose metadata from Gremlin Server to Clients.
Hi Stephen, Thanks for considering the change. We would be more inclined towards the first approach since the having a ping/pong websocket message can be a bit noisy and requires sophisticated handling on the client driver side. For handling multiple response messages. I would suggest to rely on last message as these are the metadata for request execution. Partial response is very internal to the client drivers (based on limited understanding of tinkerpop client drivers :) , correct me if you differ) and can be exposed separately (if really needed later). For implementation, Let us know if we can chip in there and submit PR. The high level approach to achieve this is to have corresponding SubmitAsynWithHeaders() for every SubmitAsync() that returns a encapsulated result with attributes and IReadOnlyCollectio. Let me know if you see any concerns adding a new API. Thanks a lot, Ashwini Singh Software Engineer @ Azure Cosmos DB -Original Message- From: Stephen Mallette <spmalle...@gmail.com> Sent: Friday, February 23, 2018 5:13 PM To: dev@tinkerpop.apache.org Subject: Re: [Discuss] Expose metadata from Gremlin Server to Clients. Adding those kinds of details was the reason we had the ResponseStatus.attributes Map. I can really only speak for the java driver as I only know that one really well (we might need other TinkerPop experts to chime in for python, .net and c#). The java driver doesn't really present ways to get that information easily under usage that doesn't deal directly with RequestMessage directly (which people typically don't do). Another thing to think about is that since a single request might return multiple ResponseMessage instances you might not want to return that kind of data on every response - maybe just to be returned on the first (or last message) and then we somehow preserve that information and make it accessible on the result somehowwe sorta have some kinda of precedent for that with side-effect data generated by bytecode based traversals - we can probably build in something similar for this sort of thing. I also toyed with the idea of using ping/pong websocket messages to carry general information about the server to the client. Not sure if any of the metadata you want to send back would fit in there, but that could be another option. Does any of that sound helpful? On Fri, Feb 23, 2018 at 3:41 PM, Ashwini Singh < ashws...@microsoft.com.invalid> wrote: > Hi All, > > We are working on to expose metadata as part of gremlin to response to > client. The metadata is simply a property bag to provide special > message/hints to the client. But currently client libraries strip off > everything and only return the data to the client. > > Specifically, We want to expose details like Request Charge, Rate > limiting/Retry policy details etc. In the other scenarios in Cosmos DB > we provide these details to the client is through response headers. We > did some investigation around this and one of the options is expose > these is through response attributes. Gremlin Server can add metadata > as part of gremlin response attributes (For example, set the property > bag on ResponseStatus.Attributes for Gremlin.Net) that can be > serialized by the client drivers to the clients. > > We would like to learn more if there are precedence around this and > if there are any recommended ways to achieve this in Gremlin protocol > and client drivers. > > Thanks a lot, > Ashwini Singh > Software Engineer @ Azure Cosmos DB > >
[Discuss] Expose metadata from Gremlin Server to Clients.
Hi All, We are working on to expose metadata as part of gremlin to response to client. The metadata is simply a property bag to provide special message/hints to the client. But currently client libraries strip off everything and only return the data to the client. Specifically, We want to expose details like Request Charge, Rate limiting/Retry policy details etc. In the other scenarios in Cosmos DB we provide these details to the client is through response headers. We did some investigation around this and one of the options is expose these is through response attributes. Gremlin Server can add metadata as part of gremlin response attributes (For example, set the property bag on ResponseStatus.Attributes for Gremlin.Net) that can be serialized by the client drivers to the clients. We would like to learn more if there are precedence around this and if there are any recommended ways to achieve this in Gremlin protocol and client drivers. Thanks a lot, Ashwini Singh Software Engineer @ Azure Cosmos DB
