Actually, let me change that up a bit. I would expect the Map to be part of
Tree, not encapsulate it. So something like :
"data":{
"@type":"g:List",
"@value":[{
"@type":"g:Tree",
"@value":[{
"@type":"g:Map",
"@value":{
"1",
{
"key":{
"@type":"g:Vertex",
"@value":{
"id":{"@type":"g:Int64","@value":1},
"label":"vertex",
"properties":{"name": ...
It could be debated that this is something the client side serializer
could/would need to add in when treating Tree. But still a little lopsided.
BTW if you're wondering, the "1" key from GRAPHSON 1.0 is a string
representation of the *element id*. So I really wouldn't be surprised if
people were using that information currently.
On Mon, Apr 16, 2018 at 4:04 PM, Dylan Millikin <[email protected]>
wrote:
> I'm going to leverage this email a bit more for the following point.
>
> I noticed that the actual format of Tree has changed with GRAPHSON 3.0.
> We're now handling Lists whereas it used to be Maps. This seems to be a
> breaking change when using GRAPHSON 3.0.
>
> Given: g.V(1).out().properties("name").tree()
>
> In 1.0 we get :
>
> "data":[{
> "1":{
> "key":{
> "id":1,
> "label":"vertex",
> "type":"vertex",
> "properties":{"name": ...
>
> In 3.0 we get :
>
> "data":{
> "@type":"g:List",
> "@value":[{
> "@type":"g:Tree",
> "@value":[{
> "key":{
> "@type":"g:Vertex",
> "@value":{
> "id":{"@type":"g:Int64","@value":1},
> "label":"vertex",
> "properties":{"name": ...
>
> When instead we should be getting :
>
> "data":{
> "@type":"g:Map",
> "@value":[{
> "1",
> {
> "@type":"g:Tree",
> "@value":[{
> "key":{
> "@type":"g:Vertex",
> "@value":{
> "id":{"@type":"g:Int64","@value":1},
> "label":"vertex",
> "properties":{"name": ...
>
> I like the new way better to be honest. And it's probably more consistent
> with gryo, but this is a breaking change and inconsistent across
> serializing methods ATM. At the very least we should add it to the upgrade
> information and perhaps consider aligning GRAPHSON 1.0 with this for 3.4
>
> Let me know if you guys think it deserves a thread of it's own. I just
> didn't want to pollute the list too much while I fiddle around.
>
> On Mon, Apr 16, 2018 at 11:27 AM, Dylan Millikin <[email protected]
> > wrote:
>
>> Ok that makes a lot of sense. I’ll change the the way the driver operates
>> to reflect that and I’ll just have the RequestMessage serialize down to a
>> native json map.
>>
>> Cheers!
>>
>> On Mon 16 Apr 2018 at 07:36, Stephen Mallette <[email protected]>
>> wrote:
>>
>>> The IO examples show that it works as you say:
>>>
>>> http://tinkerpop.apache.org/docs/current/dev/io/#_requestmessage_3
>>>
>>> I'd agree that it isn't really consistent though the "type" really isn't
>>> a
>>> g:Map i don't think - it's really a RequestMessage, but we don't have a
>>> specific type for that. Gremlin Server just understands it that way.
>>>
>>>
>>>
>>> On Mon, Apr 16, 2018 at 1:51 AM, Dylan Millikin <[email protected]>
>>> wrote:
>>>
>>> > Hey guys,
>>> >
>>> > Just been working on implementing GRAPHSON 3.0 into the php world.
>>> (testing
>>> > against gremlin-server 3.3.2)
>>> >
>>> > I noticed that the following request message fails:
>>> >
>>> > {
>>> > "@type":"g:Map",
>>> > "@value":[
>>> > "requestId","f990037e-3b55-49a4-a108-2f0e8c162715",
>>> > "processor","",
>>> > "op","eval",
>>> > "args",{"@type":"g:Map","@value":["gremlin","5+5"]}
>>> > ]
>>> > }
>>> >
>>> > While this one doesn't:
>>> >
>>> > {
>>> > "requestId":"bf26426b-ba27-475f-aafa-527ce0b0116c",
>>> > "processor":"",
>>> > "op":"eval",
>>> > "args":{"@type":"g:Map","@value":["gremlin","5+5"]}
>>> > }
>>> > }
>>> >
>>> > Seems like the parent map should not be serialized using GRAPHSON 3.0
>>> > standards. This isn't readily apparent because going through the code I
>>> > noticed both gremlin-javascript and gremlin-python seem to simply fall
>>> back
>>> > to JSON natives for this task and don't define the map type? PHP is
>>> very
>>> > much the same and I could fall back to JSON natives, but is this an
>>> > oversight? You would expect the entire "message" portion of the
>>> > Websocket RequestMessage
>>> > to be serialized by the same standard.
>>> >
>>> > I've overall done a decent job of staying up to date with the mailing
>>> list
>>> > (even though I haven't participated) but I may have overlooked this
>>> already
>>> > being discussed. If anyone has a tldr regarding this that would be
>>> great?
>>> >
>>> > Thanks!
>>> >
>>> > FYI : error message for the first one, it seems to choke on the @value
>>> > List.
>>> >
>>> > [WARN] AbstractGraphSONMessageSerializerV2d0 - Request
>>> > [PooledUnsafeDirectByteBuf(ridx: 158, widx: 158, cap: 175)] could not
>>> be
>>> > deserialized by org.apache.tinkerpop.gremlin.driver.ser.
>>> > AbstractGraphSONMessageSerializerV2d0.
>>> > org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException:
>>> Could
>>> > not deserialize the JSON value as required. Nested exception:
>>> > java.lang.InstantiationException:
>>> > Cannot deserialize the value with the detected type contained in the
>>> JSON
>>> > ('g:Map') to the type specified in parameter to the object mapper
>>> (class
>>> > org.apache.tinkerpop.gremlin.driver.message.RequestMessage). Those
>>> types
>>> > are incompatible.
>>> > at [Source: (byte[])"{"@type":"g:Map","@va
>>> lue":["requestId","f990037e-
>>> > 3b55-49a4-a108-2f0e8c162715","processor","","op","eval","
>>> > args",{"@type":"g:Map","@value":["gremlin","5+5"]}]}"; line: 1,
>>> column:
>>> > 27]
>>> >
>>>
>>
>
