> I think it would be best if, all Strings, numerics, nulls, other primitive types, all enums (like cardinality, column, direction etc), datetime, uuid, graph elements (Vertex, Edge, Properties) will be part of string representation of traversal and if all collections (array/list, map, set), complex types and some graph specific objects (path, graph, tree) will be send as query parameters.
As I think about this choice, I wonder if greater user control might be needed for determining what arguments become parameters. The use of parameters helps with caching the query plan. For Groovy, that just meant you cached the compiled version of the parameterized query, but with gremlin-language I could see where providers with their own query engines could make use of parameterized queries more directly. If we restrict parameters to just collections and complex types we miss those caching opportunities. On the other hand, it might not make sense to parameterize "everything" either as we could lose some context that is important to an optimization. For Bytecode there were Bindings, which happened to not have much effect on performance unless the Bytecode was processed in Groovy rather than the JavaTranslator. The reliance on ThreadLocal wasn't too nice (but necessary given the code structure) and I don't know the extent to which other language variants made use of that. We may need a similar mechanism to properly do this. One other thing that creeps into my mind is that there are use cases where including a collection as its string representation will be helpful or maybe even necessary (i find that less so for graph objects which are not really used as arguments). If they only appear as query parameters it makes some simple outputs less readable. I'm not sure what the right approach is, but I sense users will need more control here and require it in all the programming languages. On Mon, Jun 10, 2024 at 3:35 PM Valentyn Kahamlyk <valen...@apache.org> wrote: > Hi all, > > I'm working on moving forward with bytecode removal that was mentioned > previously in this thread. When traversals create their Gremlin string > representations, I think it would be best if, all Strings, numerics, nulls, > other primitive types, all enums (like cardinality, column, direction etc), > datetime, uuid, graph elements (Vertex, Edge, Properties) will be part of > string representation of traversal and if all collections (array/list, map, > set), complex types and some graph specific objects (path, graph, tree) > will be send as query parameters. This will keep the request understandable > when you need to transfer a large amount of data. > > I'm still trying to think through custom types and how those will work > because the custom serializer mechanism is a bit burdensome, but for now it > will stay as it is. Perhaps, some some syntax could be added to allow for > custom(String typeName, String value) in the grammar. Or, we could perhaps > just recommend `call` step. > > One issue I'm noticing in doing this work is that there are some > compatibility issues between gremlin-groovy and gremlin-language where the > string I'm generating is only compatible with the latter for certain cases. > For example, the suffix for BigDecimal is not same, 'g' for groovy and 'm' > for gremlin-language. I'm thinking we could pass the generated > gremlin-language string through the new translators that are built on the > grammar and use them to produce appropriate groovy. > > Regards, > Valentyn >
