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 <dylan.milli...@gmail.com>
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 <dylan.milli...@gmail.com
> > 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 <spmalle...@gmail.com>
>> 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 <dm...@apache.org>
>>> 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]
>>> >
>>>
>>
>

Reply via email to