[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&focusedCommentId=16411231#comment-16411231 ] ASF GitHub Bot commented on TINKERPOP-1909: --- Github user asfgit closed the pull request at: 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-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&focusedCommentId=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-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&focusedCommentId=16410524#comment-16410524 ] ASF GitHub Bot commented on TINKERPOP-1909: --- GitHub user ashwini-ms opened a pull request: https://github.com/apache/tinkerpop/pull/824 Uniform object model for GraphSON response for client drivers Based on the discussion here: [](https://issues.apache.org/jira/browse/TINKERPOP-1909) You can merge this pull request into a Git repository by running: $ git pull https://github.com/ashwini-ms/tinkerpop master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/824.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #824 commit ba915458a3d4121a55d563dfc8267417574c8f94 Author: Ashwini Singh <30875507+ashwini-ms@...> Date: 2018-03-22T22:42:43Z update index.asciidoc Add design doc for reference based object model commit 79dc2cdf157a4df688a68f80100e6aecefcc28b9 Author: Ashwini Singh <30875507+ashwini-ms@...> Date: 2018-03-22T22:43:44Z fix format fixing format > 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-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&focusedCommentId=16392833#comment-16392833 ] stephen mallette commented on TINKERPOP-1909: - We've established a distinction between a GLV (currently Python, .NET and Javascript) and a full Gremlin Virtual Machine (GVM) implementation of TinkerPop (currently just the JVM - which would include Java, Groovy, as well as third-party libraries like gremlin-scala, ogre and perhaps others). The difference in the object model is related to that distinction. A GLV holds a more lightweight object model than a full GVM. I earlier referenced TINKERPOP-1417 because I believe that presents one of the first steps to bridging that gap, but I don't believe we are ready to make that kind of move just yet (again, something for the distant 4.x probably). I'm against expanding the object model at this time as I feel like we went into long discussion on this leading up to 3.3.0 and we came away with these current definitions of GLV versus GVM versus TINKERPOP-1417. Given that we spent as much time on that as we did, I think it would be smart to maintain course as they are through at least 3.4.0. I personally waffled back and forth forever on it and the discussion is wickedly hard to follow because it took a while to clarify the difference between GLV and GVM (though Marko had it straight in his head from the beginning with his view of things) which is evident in a web of JIRA issues and mailing list discussion (this issue touches on some of this discussion and connects to other areas of relevance - TINKERPOP-1474) Anecdotally, I'll say that I've not witnessed many users struggling with the current object model (no issues have been raised to me from customers at my company and the mailing list is usually pretty silent about it - occasionally someone might ask about it, but they quickly grasp that SQL metaphor I provided earlier and, to my knowledge, move on). I think that the root of that lies in the fact that once you really start to develop applications you typically don't return graph elements as your answers. you return the data and that data has a shape that is not in the shape of a vertex/edge. It comes in the form of lists/maps. Anyway, I hope it's clear that I'm just offering my opinion here on the direction that should be taken for the immediate needs of 3.2.x, 3.3.x and 3.4.x. I think I'd like to see how the current design plays out before reversing it. Gremlin-Javascript hasn't even had a release yet to hear feedback from that community and the .NET release is just one official release old. I think we should see how things develop in each of these GLVs before undertaking this discussion again. If you still feel differently, feel free to start a DISCUSS thread on the dev mailing list about it and see if anyone in the community wants to engage - it's obviously a community decision to make and not mine alone. > 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-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&focusedCommentId=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)
[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&focusedCommentId=16387868#comment-16387868 ] stephen mallette commented on TINKERPOP-1909: - Ok - to simplify our discussion, I think we should drop any design ideas for potential inclusion in 4.x from this issue - that's a long long way off. So 3.x talk only - perhaps we start by exploring your suggestion that you made a few comments back: "let applications extend the object model + deserializers if required". I'm not sure what that would entail to TinkerPop - have you given any thought to that as of yet? finally, just a quick response to your question about bulk insert wrt to 4.x - i don't think we have one yet, however, i still very much like the idea of shipping around client side subgraphs that can be merged into a main graph in a single transaction. That is somewhat akin to your idea there of submitting a full graphson file (containing a subgraph) to the server for insert. To me, this approach would solve a great many user problems regarding transactions, bulk updates/inserts mechanics, performance, etc., but it would likely mean some challenges for TinkerPop and graph providers. TinkerPop would need to build out more infrastructure in GLVs to support something like that and there would have to be some way for TinkerPop and/or graph providers to handle the merge of that subgraph on update. Anyway, that's my idea for now - it certainly requires more discussion. > 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-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&focusedCommentId=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)
[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&focusedCommentId=16386048#comment-16386048
]
stephen mallette commented on TINKERPOP-1909:
-
I'm not completely for or against any particular ideas for TinkerPop 4.x at
this point as we're largely just collecting ideas on how that version should be
shaped. I'd established this document for that purpose:
http://tinkerpop.apache.org/docs/current/dev/future/
It has no really set format at this point - just a scratchpad. You can submit
pull requests with thoughts if you like:
https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/index.asciidoc
Regarding the options you present:
1. As to your first suggestionI prefer the idea of just reference objects
(i.e. id/label) for a variety of reasons, but going back to my initial comment,
I think we can only do that reasonably if we have a method to properly handle
remote transactions that doesn't require the full object model on the client.
Of course, it seems to be possible to envision TINKERPOP-1417 without a full
object model given the design marko put forward in the "future" doc. In fact,
that works quite well in my mind now as I type this. It would truly be a
unified way to do Gremlin. Whether you are talking to a local subgraph or a
remote multi-billion edge graph your results are always just a "reference". The
part that seems to fail would be in the gathering of an initial subgraph for a
transaction. Somehow that local subgraph would have to be populated in an
efficient fashion.
2. As to your second suggestionI think that an extension model could make
sense. That would allow TinkerPop to stay on the track for "reference" objects
but allow graph providers and users to extend that model. We've tried to offer
such a model already with the {{IoRegistry}} system in java, but I'm not sure
it has this entire use case in mind thought through and I'm not sure it follows
through well to all the GLVs, like .NET.
Anyway, I think that we should move any further 4.x discussion to the "future"
doc. I'll leave this ticket open for a bit to see if you have any reply before
I grab any key points from here and move them over there. Thanks for your input.
> 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-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&focusedCommentId=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] [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&focusedCommentId=16384412#comment-16384412
]
stephen mallette commented on TINKERPOP-1909:
-
There has been much discussion on this topic and as it stands right now the
general consensus in the community is to not include properties with graph
elements (vertices/edges/vertexproperties) and we will only return the
"reference" (i.e. id/label). There are a number of reasons for this, but i
think that one of the important ones is that users should be encouraged to only
return the data that they need. I tend to use the example with SQL where you
would typically not write a query like {{SELECT * FROM table}}}. The same
applies to graphs. You would write your traversal so as to only return the
properties that you needed. Returning an entire vertex could open up really big
performance problems especially with multi-properties. It is better to just not
allow it.
The general thinking is that a future TinkerPop 4.x will be more tidy in this
regard (where the JVM side doesn't have properties while other languages do not
as it is now in TinkerPop 3.x). That's a bit of an unfortunate side of effect
of our late term development of GLVs (we had no idea that we would be doing
such a thing for 3.x). I do have some reservation about this model for 4.x
though, as I would like to improve the transactional model for TinkerPop 4.x
and I think that client side subgraphs could provide the answer to that - see
TINKERPOP-1417 for some thoughts on that.
> 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)
