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
> >
>
