[
https://issues.apache.org/jira/browse/TINKERPOP-2067?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16651424#comment-16651424
]
Florian Hockmann commented on TINKERPOP-2067:
---------------------------------------------
I guess that's a valid use case and it should work in general like you
described. Our tests should also show whether this introduces any problems but
that would really surprise me if your change really only affects cases where
{{typeof(T) == typeof(JToken)}}.
So, I'd say maybe wait a few days in case someone else has good reasons against
this change / ideas for a better solution and then create a PR. BTW, {{tp33}}
would be the appropriate base branch for this change after our upcoming release
of 3.2.10/3.3.4.
> Allow getting raw data from Gremlin.Net.Driver.IGremlinClient
> -------------------------------------------------------------
>
> Key: TINKERPOP-2067
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2067
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
> Reporter: Daniel C. Weber
> Priority: Minor
>
> I am developing an ORM-style [server driver for
> Gremlin|https://github.com/ExRam/ExRam.Gremlinq]. To communicate with
> Gremlin-servers, I rely on
> [Gremlin.net|https://github.com/ExRam/ExRam.Gremlinq/tree/master/ExRam.Gremlinq.Providers.WebSocket].
> Since ExRam.Gremlinq deals with deserializing Json data to POCOs by itself,
> it needs to get raw data from an IGremlinClient. Currently, it's only safe to
> use SubmitAsync<T> with object or dynamic as T, or other (scalar) types if
> known it advance. To get a raw JToken, I currently use a
> [hack|https://github.com/ExRam/ExRam.Gremlinq/blob/master/ExRam.Gremlinq.Providers.WebSocket/GremlinClientQueryProvider.cs#L34].
> The hack is not only ugly, it prohibits users of ExRam.Gremlinq to create and
> pass in instances of IGremlinClient by themselves, which could become
> necessary e.g. for adjusting the Graphson version etc.
> I had a look into the sources of Gremlin.net. It deserializes a server's
> answer to a ResponseMessage<JToken>, so the JToken is available in any case.
> It would be a trivial change to check the type parameter T and return the
> token if typeof(T) == typeof(JToken), and I could definitely file the PR for
> that. However, I'm of course less aware of possible unintended implications.
> Any thoughts are appreciated!
>
> thx
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
