[
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 suggestion....I 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 suggestion....I 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)
