[
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)
