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

Reply via email to