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

Reply via email to