Yes, that answers my question.
Thanks
On 2026/06/04 03:24:33 Ken Hu wrote:
> Hi Valentyn,
>
> In short, it won't be stored in plain JSON. I'm not sure if you are asking
> about gremlin-lang or gremlin-groovy with your query, but since it uses the
> (byte) casting I'm going to assume gremlin-groovy. Either way, the JSON
> request just carries the query as a plain string in the "gremlin" field.
> That exact query you mentioned would have to be processed using
> gremlin-groovy which requires the "language" field to be set to
> "gremlin-groovy". The "gremlin-lang" equivalent
> is "g.V(1).property('test',['long':1L,'int':1,'byte':1B])". JSON is just a
> transport for the query string, the type information is part of the query
> language.
>
> Does that answer your question or did I misunderstand the question?
>
> Regards,
> Ken
>
> On Wed, Jun 3, 2026 at 3:48 PM Valentyn Kahamlyk <[email protected]>
> wrote:
>
> > Hi Ken,
> >
> > Could you provide an example how type information will be stored in plain
> > JSON for query `g.V(1).property("test",["long":1L,"int":1,"byte":(byte)1])`?
> >
> > Thanks, Valentyn
> >
> > On 2026/05/30 04:29:00 Ken Hu wrote:
> > > I propose we change all Gremlin Language Variants (Java, Python, Go,
> > .NET,
> > > JavaScript) to serialize their HTTP request bodies as plain JSON
> > > (application/json) instead of GraphBinary. Responses remain GraphBinary.
> > > This applies to the 4.x line. The recent change to make
> > bindings/parameters
> > > gremlin-lang string enables this as there are no longer any complex
> > fields,
> > > only scalars.
> > >
> > > This is beneficial in several ways:
> > >
> > > Lowered maintenance cost across five languages since every GLV currently
> > > maintains a GraphBinary request writer in addition to the reader. JSON
> > > serialization is built into every language's standard library.
> > Eventually,
> > > dropping the request writer from the default path removes a meaningful
> > > chunk of per-language code that has to be kept correct and in sync.
> > >
> > > The server already accepts "application/json" requests, that's what curl,
> > > Postman, and third-party HTTP clients use. Today no GLV exercises that
> > > path, so a regression in JSON request parsing could ship undetected.
> > Moving
> > > the GLVs onto JSON means the existing cross-GLV integration suite
> > > continuously validates the same code path external consumers depend on.
> > >
> > > A JSON request body is human-readable on the wire and in logs.
> > Diagnosing a
> > > malformed request no longer requires decoding a binary buffer, and
> > > provider-specific extensions are easier to add and inspect. This is
> > > especially helpful when writing interceptors as you won't have to deal
> > with
> > > the GraphBinary-serialized bytes. It's easy to inspect UTF-8 encoded
> > bytes.
> > >
> > > Does anyone have any thoughts on this?
> > >
> > > Thanks,
> > > Ken
> > >
> >
>
