[jira] [Updated] (TINKERPOP-2179) Have o.a.t.g.driver.ser.SerializationException extend IOException
[
https://issues.apache.org/jira/browse/TINKERPOP-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Gallardo updated TINKERPOP-2179:
--
Description:
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. Also being
able to catch IOException there would allow to be more generic.
was:
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if we SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. Also being
able to catch IOException there would allow to be more generic.
> Have o.a.t.g.driver.ser.SerializationException extend IOException
> -
>
> Key: TINKERPOP-2179
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2179
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.3.5
>Reporter: Kevin Gallardo
>Priority: Major
>
> Suggestion to have the SerializationException from gremlin extend Java's
> IOException. Some other libraries like Jackson do it.
> In Java 8 there is a new {{UncheckedIOException()}} that can be created and
> thrown at runtime, except it requires the underlying exception to be an
> IOException.
> Ideally if SerializationException extended IOException we could do something
> like:
> {code:java}
> try {
> GraphBinaryWriter.write(object, bytebuf);
> } catch (IOException e) {
> throw new UncheckedIOException("Could not serialize", e)
> }
> {code}
> So that the calling code does not throw a checked exception anymore. Also
> being able to catch IOException there would allow to be more generic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2179) Have o.a.t.g.driver.ser.SerializationException extend IOException
[
https://issues.apache.org/jira/browse/TINKERPOP-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Gallardo updated TINKERPOP-2179:
--
Description:
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if we SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. Also being
able to catch IOException there would allow to be more generic.
was:
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if we SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. -Also
being able to catch IOException there would allow to be more generic.-
> Have o.a.t.g.driver.ser.SerializationException extend IOException
> -
>
> Key: TINKERPOP-2179
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2179
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.3.5
>Reporter: Kevin Gallardo
>Priority: Major
>
> Suggestion to have the SerializationException from gremlin extend Java's
> IOException. Some other libraries like Jackson do it.
> In Java 8 there is a new {{UncheckedIOException()}} that can be created and
> thrown at runtime, except it requires the underlying exception to be an
> IOException.
> Ideally if we SerializationException extended IOException we could do
> something like:
> {code:java}
> try {
> GraphBinaryWriter.write(object, bytebuf);
> } catch (IOException e) {
> throw new UncheckedIOException("Could not serialize", e)
> }
> {code}
> So that the calling code does not throw a checked exception anymore. Also
> being able to catch IOException there would allow to be more generic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2179) Have o.a.t.g.driver.ser.SerializationException extend IOException
[
https://issues.apache.org/jira/browse/TINKERPOP-2179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Gallardo updated TINKERPOP-2179:
--
Description:
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if we SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. -Also
being able to catch IOException there would allow to be more generic.-
was:
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if we SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. Also being
able to catch IOException there would allow to be more generic.
> Have o.a.t.g.driver.ser.SerializationException extend IOException
> -
>
> Key: TINKERPOP-2179
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2179
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.3.5
>Reporter: Kevin Gallardo
>Priority: Major
>
> Suggestion to have the SerializationException from gremlin extend Java's
> IOException. Some other libraries like Jackson do it.
> In Java 8 there is a new {{UncheckedIOException()}} that can be created and
> thrown at runtime, except it requires the underlying exception to be an
> IOException.
> Ideally if we SerializationException extended IOException we could do
> something like:
> {code:java}
> try {
> GraphBinaryWriter.write(object, bytebuf);
> } catch (IOException e) {
> throw new UncheckedIOException("Could not serialize", e)
> }
> {code}
> So that the calling code does not throw a checked exception anymore. -Also
> being able to catch IOException there would allow to be more generic.-
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2179) Have o.a.t.g.driver.ser.SerializationException extend IOException
Kevin Gallardo created TINKERPOP-2179:
-
Summary: Have o.a.t.g.driver.ser.SerializationException extend
IOException
Key: TINKERPOP-2179
URL: https://issues.apache.org/jira/browse/TINKERPOP-2179
Project: TinkerPop
Issue Type: Improvement
Reporter: Kevin Gallardo
Suggestion to have the SerializationException from gremlin extend Java's
IOException. Some other libraries like Jackson do it.
In Java 8 there is a new {{UncheckedIOException()}} that can be created and
thrown at runtime, except it requires the underlying exception to be an
IOException.
Ideally if we SerializationException extended IOException we could do something
like:
{code:java}
try {
GraphBinaryWriter.write(object, bytebuf);
} catch (IOException e) {
throw new UncheckedIOException("Could not serialize", e)
}
{code}
So that the calling code does not throw a checked exception anymore. Also being
able to catch IOException there would allow to be more generic.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2097) Create a DriverRemoteConnection with an initialized Client
Kevin Gallardo created TINKERPOP-2097:
-
Summary: Create a DriverRemoteConnection with an initialized Client
Key: TINKERPOP-2097
URL: https://issues.apache.org/jira/browse/TINKERPOP-2097
Project: TinkerPop
Issue Type: Improvement
Components: driver
Affects Versions: 3.3.4
Reporter: Kevin Gallardo
Currently the only way to create a {{DriverRemoteConnection}} is by providing a
Cluster or a Configuration, which will then initialize a {{Client}} internally.
Users have to create a new {{Client}} for every {{DriverRemoteConnection}}.
It would be convenient to add the possibility to provide an already initialized
{{Client}} so that you don't cause a new connection to the server for each
{{DriverRemoteConnection}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2028) AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule when mapper is provided
[
https://issues.apache.org/jira/browse/TINKERPOP-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16595266#comment-16595266
]
Kevin Gallardo commented on TINKERPOP-2028:
---
Re-registering doesn't sound problematic from what I can see.
I'm making a PR for this, will test that.
> AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule
> when mapper is provided
> -
>
> Key: TINKERPOP-2028
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2028
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.1, 3.2.9
>Reporter: Kevin Gallardo
>Priority: Major
>
> When specifying a {{GraphSONMapper}} when constructing a
> {{GraphSONMessageSerializerV3d0}}, the Message serializer will not register
> any module. Hence users will have to manually register the
> {{GremlinServerModule}} to the GraphSONMapper they are giving in parameter
> for it to work at all:
> {code:java}
> GraphSONMessageSerializerV3d0 messageSerializerV3d0 =
> new GraphSONMessageSerializerV3d0(
> GraphSONMapper.build()
> .version(GraphSONVersion.V3_0)
> .addCustomModule(new
> AbstractGraphSONMessageSerializerV2d0.GremlinServerModule())
> .addRegistry(TinkerIoRegistryV3d0.instance()).create());
> {code}
> When not providing a Mapper, the GremlinServerModule is registered
> automatically. It sounds reasonable in the context of the
> {{GraphSONMessageSerializer}} to automatically register the
> {{GremlinServerModule}} wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2028) AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule when mapper is provided
[
https://issues.apache.org/jira/browse/TINKERPOP-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Gallardo updated TINKERPOP-2028:
--
Summary: AbstractGraphSONMessageSerializerV2d0 should register
GremlinServerModule when mapper is provided (was:
AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule if
mapper is provided)
> AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule
> when mapper is provided
> -
>
> Key: TINKERPOP-2028
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2028
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.1, 3.2.9
>Reporter: Kevin Gallardo
>Priority: Major
>
> When specifying a {{GraphSONMapper}} when constructing a
> {{GraphSONMessageSerializerV3d0}}, the Message serializer will not register
> any module. Hence users will have to manually register the
> {{GremlinServerModule}} to the GraphSONMapper they are giving in parameter
> for it to work at all:
> {code:java}
> GraphSONMessageSerializerV3d0 messageSerializerV3d0 =
> new GraphSONMessageSerializerV3d0(
> GraphSONMapper.build()
> .version(GraphSONVersion.V3_0)
> .addCustomModule(new
> AbstractGraphSONMessageSerializerV2d0.GremlinServerModule())
> .addRegistry(TinkerIoRegistryV3d0.instance()).create());
> {code}
> When not providing a Mapper, the GremlinServerModule is registered
> automatically. It sounds reasonable in the context of the
> {{GraphSONMessageSerializer}} to automatically register the
> {{GremlinServerModule}} wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2028) AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule if mapper is provided
[
https://issues.apache.org/jira/browse/TINKERPOP-2028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Gallardo updated TINKERPOP-2028:
--
Summary: AbstractGraphSONMessageSerializerV2d0 should register
GremlinServerModule if mapper is provided (was: GraphSONMessageSerializerV3d0
should register GremlinServerModule)
> AbstractGraphSONMessageSerializerV2d0 should register GremlinServerModule if
> mapper is provided
> ---
>
> Key: TINKERPOP-2028
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2028
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.1, 3.2.9
>Reporter: Kevin Gallardo
>Priority: Major
>
> When specifying a {{GraphSONMapper}} when constructing a
> {{GraphSONMessageSerializerV3d0}}, the Message serializer will not register
> any module. Hence users will have to manually register the
> {{GremlinServerModule}} to the GraphSONMapper they are giving in parameter
> for it to work at all:
> {code:java}
> GraphSONMessageSerializerV3d0 messageSerializerV3d0 =
> new GraphSONMessageSerializerV3d0(
> GraphSONMapper.build()
> .version(GraphSONVersion.V3_0)
> .addCustomModule(new
> AbstractGraphSONMessageSerializerV2d0.GremlinServerModule())
> .addRegistry(TinkerIoRegistryV3d0.instance()).create());
> {code}
> When not providing a Mapper, the GremlinServerModule is registered
> automatically. It sounds reasonable in the context of the
> {{GraphSONMessageSerializer}} to automatically register the
> {{GremlinServerModule}} wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2028) GraphSONMessageSerializerV3d0 should register GremlinServerModule
Kevin Gallardo created TINKERPOP-2028:
-
Summary: GraphSONMessageSerializerV3d0 should register
GremlinServerModule
Key: TINKERPOP-2028
URL: https://issues.apache.org/jira/browse/TINKERPOP-2028
Project: TinkerPop
Issue Type: Bug
Components: io
Affects Versions: 3.2.9, 3.3.1
Reporter: Kevin Gallardo
When specifying a {{GraphSONMapper}} when constructing a
{{GraphSONMessageSerializerV3d0}}, the Message serializer will not register any
module. Hence users will have to manually register the {{GremlinServerModule}}
to the GraphSONMapper they are giving in parameter for it to work at all:
{code:java}
GraphSONMessageSerializerV3d0 messageSerializerV3d0 =
new GraphSONMessageSerializerV3d0(
GraphSONMapper.build()
.version(GraphSONVersion.V3_0)
.addCustomModule(new
AbstractGraphSONMessageSerializerV2d0.GremlinServerModule())
.addRegistry(TinkerIoRegistryV3d0.instance()).create());
{code}
When not providing a Mapper, the GremlinServerModule is registered
automatically. It sounds reasonable in the context of the
{{GraphSONMessageSerializer}} to automatically register the
{{GremlinServerModule}} wdyt?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1942) Binary serialization format
[ https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16508209#comment-16508209 ] Kevin Gallardo commented on TINKERPOP-1942: --- (again, I may be missing some context because not caught-up on the conversation) - Having the types specification extensible is currently a feature of GraphSON that database vendors use to implement their own data types that are specific to the vendor's storage. The Gremlin server also currently allows you to customize the supported types by providing additional I/o registries to the server's configuration, so removing that possibility does not seem in-line with what the "Server framework" currently supports. > Binary serialization format > --- > > Key: TINKERPOP-1942 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1942 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > We should provide a binary serialization format designed to reduce > serialization overhead and minimizing the size of the payload that is > transmitted over the wire. > It could be implemented in a very similar way as Kryo support but with > interoperability in mind and ultimately we could fade Gryo out, as now with > the GLVs it doesn't have a role to play. > The main benefit would be the performance improvement, making serialization > and deserialization processing time negligible on both the server and the > client. > Background: > https://lists.apache.org/thread.html/13e70235591853801bab16ed457ee4f56f3dfe2d1c5817c34a036408@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (TINKERPOP-1942) Binary serialization format
[ https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506291#comment-16506291 ] Kevin Gallardo edited comment on TINKERPOP-1942 at 6/11/18 2:57 PM: Hi all, will throw this out there: TIL about a binary format developed by the team from Jackson: [https://github.com/FasterXML/smile-format-specification] supposedly this format has the same characteristics as JSON in terms of composability, so maybe something that could be for use here. If this fits the use case it would allow not having to re-create a new format from scratch, it would also mean that this comes with already some libraries supposedly optimized for example in Java and others like the current Jackson libraries are. Disclaimer: Unfortunately I haven't had a chance to follow the full conversation here yet but wanted to mention that if anybody wants to have a look. was (Author: newkek): Hi all, will throw this out there: TIL about a binary format developed by the team from Jackson: [https://github.com/FasterXML/smile-format-specification] supposedly this format has the same characteristics as JSON in terms of composability, so maybe something that could be for use here. If this fits the use case it would allow to having to re-create a new format from scratch, it would also mean that this comes with already some libraries supposedly optimized for example in Java and others like the current Jackson libraries are. Disclaimer: Unfortunately I haven't had a chance to follow the full conversation here yet but wanted to mention that if anybody wants to have a look. > Binary serialization format > --- > > Key: TINKERPOP-1942 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1942 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > We should provide a binary serialization format designed to reduce > serialization overhead and minimizing the size of the payload that is > transmitted over the wire. > It could be implemented in a very similar way as Kryo support but with > interoperability in mind and ultimately we could fade Gryo out, as now with > the GLVs it doesn't have a role to play. > The main benefit would be the performance improvement, making serialization > and deserialization processing time negligible on both the server and the > client. > Background: > https://lists.apache.org/thread.html/13e70235591853801bab16ed457ee4f56f3dfe2d1c5817c34a036408@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1942) Binary serialization format
[ https://issues.apache.org/jira/browse/TINKERPOP-1942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16506291#comment-16506291 ] Kevin Gallardo commented on TINKERPOP-1942: --- Hi all, will throw this out there: TIL about a binary format developed by the team from Jackson: [https://github.com/FasterXML/smile-format-specification] supposedly this format has the same characteristics as JSON in terms of composability, so maybe something that could be for use here. If this fits the use case it would allow to having to re-create a new format from scratch, it would also mean that this comes with already some libraries supposedly optimized for example in Java and others like the current Jackson libraries are. Disclaimer: Unfortunately I haven't had a chance to follow the full conversation here yet but wanted to mention that if anybody wants to have a look. > Binary serialization format > --- > > Key: TINKERPOP-1942 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1942 > Project: TinkerPop > Issue Type: Improvement > Components: io >Reporter: Jorge Bay >Priority: Major > > We should provide a binary serialization format designed to reduce > serialization overhead and minimizing the size of the payload that is > transmitted over the wire. > It could be implemented in a very similar way as Kryo support but with > interoperability in mind and ultimately we could fade Gryo out, as now with > the GLVs it doesn't have a role to play. > The main benefit would be the performance improvement, making serialization > and deserialization processing time negligible on both the server and the > client. > Background: > https://lists.apache.org/thread.html/13e70235591853801bab16ed457ee4f56f3dfe2d1c5817c34a036408@%3Cdev.tinkerpop.apache.org%3E -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1738) Proper functioning of GraphSONReader depends on order of elements in String representation
[
https://issues.apache.org/jira/browse/TINKERPOP-1738?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16364747#comment-16364747
]
Kevin Gallardo commented on TINKERPOP-1738:
---
Hm well if I remember correctly the issue is that we were *not* getting the
error consistently previously.
I.e. if trying to deserialize a value out of bounds for a int32 you should get
an error. However with the GraphSON2+ deserialization mechanism sometimes
(depending on the order of the values) the deserialization would happen in a
_Jackson_ TokenBuffer internally and in this TokenBuffer class the out-of-bound
wasn't taken into account and deserialized wrong. With the fix in Jackson now
if calling TokenBuffer.getIntValue() and the content is out-of-bound of an int
you would get an exception too.
TL;DR:
{code:java}
'{"@value":{"step":[["addV","poc_int"],["property","bigint1value",{"@value":-4294967295,"@type":"g:Int32"}]]},"@type":"g:Bytecode"}'{code}
and
{code:java}
'{"@type":"g:Bytecode","@value":{"step":[["addV","poc_int"],["property","bigint1value",{"@type":"g:Int32","@value":-4294967295}]]}}'{code}
Should in theory both fail now because trying to deserialize an int that
doesn't fit into an int.
> Proper functioning of GraphSONReader depends on order of elements in String
> representation
> --
>
> Key: TINKERPOP-1738
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1738
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.0
>Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> The following two snippets are basically using the same stringified JSON
> object, it's just the order of elements that is different.
> {noformat}
> gremlin> GraphSONReader.build().create().readObject(new
> java.io.ByteArrayInputStream('{"@value":{"step":[["addV","poc_int"],["property","bigint1value",{"@value":-4294967295,"@type":"g:Int32"}]]},"@type":"g:Bytecode"}'.getBytes()),
> Bytecode.class)
> ==>[[], [addV(poc_int), property(bigint1value, 1)]]
> {noformat}
> {noformat}
> gremlin> GraphSONReader.build().create().readObject(new
> java.io.ByteArrayInputStream('{"@type":"g:Bytecode","@value":{"step":[["addV","poc_int"],["property","bigint1value",{"@type":"g:Int32","@value":-4294967295}]]}}'.getBytes()),
> Bytecode.class)
> Could not deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not
> deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.core.JsonParseException: Numeric value
> (-4294967295) out of range of int
> at [Source: java.io.ByteArrayInputStream@6d367020; line: 1, column: 126]
> at [Source: java.io.ByteArrayInputStream@6d367020; line: 1, column: 115]
> (through reference chain: java.util.ArrayList[1]->java.util.ArrayList[2])
> at [Source: java.io.ByteArrayInputStream@6d367020; line: 1, column: 115]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164873#comment-16164873
]
Kevin Gallardo commented on TINKERPOP-1474:
---
re: GraphSON:
The GraphSON spec [as detailed
here|http://tinkerpop.apache.org/docs/3.3.0/dev/io/#_vertex_3] mentions
properties being serialized as part of the Vertex and that's what I was
referring to If Tinkerpop were to decide that properties are fully separate
from Vertex then the GraphSON spec should reflect it, since in GraphSON there
is no notion of "g:DetachedVertex" or "g:ReferenceVertex" - everything is
Vertex, so the serialization specs should align with that I think.
About properties, (I know this is a long term goal and you're still only
thinking about it but) to me it seems the most natural that Properties get
serialized separately from Vertices and Edges and simply contain a reference
(ID) to their parent element to allow re-attaching to it.
> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164774#comment-16164774
]
Kevin Gallardo commented on TINKERPOP-1474:
---
So the only way to gather properties will be explicitly through the traversal
then, I guess, interesting. Makes sense to me.
Just realized that the GraphSON specification will need to be updated once that
happens.
> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16164742#comment-16164742
]
Kevin Gallardo commented on TINKERPOP-1474:
---
[~spmallette] so is the goal for the Java GLV to have the Vertex class be
removed of its Properties methods? Like {{v.property('name')}}, etc etc
I think the issue here was more about the Graph {{structure}} objects like
Vertex, Edge, and so on which do not have a properties in the class definition
itself. In Java, whether the object sent over the wire is a Detached or
Reference element, the object returned by the Tinkerpop API always extends
Vertex, which has an API for properties even though if the object sent is a
Reference, calling to properties will return empty results. In the Python GLV,
currently whether a Vertex sent is Detached or Reference, the Vertex class does
not have an API to gather properties out of the Vertex.
> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>Assignee: stephen mallette
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (TINKERPOP-1740) Add vertex parameter overload to to() and from()
[
https://issues.apache.org/jira/browse/TINKERPOP-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16111726#comment-16111726
]
Kevin Gallardo commented on TINKERPOP-1740:
---
I think it'd be worth having the {{addE()}} step on the TraversalSource so that
you can simply call for adding an edge without having to initiate a Traversal
with {{g.V(vertex)}}. Considering you have already fetched 2 vertices earlier
you may want to simply add an edge between the two:
{code}
Vertex a = g.addV().next();
Vertex b = g.addV().next();
g.addE("knows").from(a.id()).to(b.id()).next();
// or combined with this proposed solution
g.addE("knows").from(a).to(b).next()
{code}
> Add vertex parameter overload to to() and from()
>
>
> Key: TINKERPOP-1740
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1740
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>
> Make it possible to do this:
> {code}
> a = g.V(1).next()
> b = g.V(2).next()
> g.V(a).addE("friend").to(b)
> {code}
> This will work {{withRemote()}} given that detached elements are re-attached
> prior to usage with {{AddEdgeStep}}.
> Right now you have to do the above with the ugly {{withSideEffects}} prefix
> appendage.
> {code}
> a = g.addV().next()
> b = g.addV().next()
> g.withSideEffect('b',b).V(a).addE('friend').to('b')
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (TINKERPOP-1445) Large nested VertexProperties and Properties do not get printed well
[
https://issues.apache.org/jira/browse/TINKERPOP-1445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Gallardo updated TINKERPOP-1445:
--
Issue Type: Improvement (was: Bug)
> Large nested VertexProperties and Properties do not get printed well
>
>
> Key: TINKERPOP-1445
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1445
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.2
>Reporter: Kevin Gallardo
>Priority: Minor
>
> {code}
> gremlin> m = ['hello':'world', 'helo':'fromtheotherside']
> ==>hello=world
> ==>helo=fromtheotherside
> gremlin> graph.traversal().E().next().property('longMap', m)
> ==>p[longMap->{hello=world, helo=f]
> {code}
> Maybe the printing could be improved just to at least inform that there's
> more in the value with a {{...}} or {{\[...\]}} for example.
> It seems to be the {{substring()}} call in
> [propertyString|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/StringFactory.java#L113].
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15715792#comment-15715792
]
Kevin Gallardo commented on TINKERPOP-1565:
---
Here's my thoughts on a more broader angle then, I do not disagree with the
idea of selecting which kind of serialization you want to have, in order to
allow more possibilities wrt to attachment, or lightness, although I would
like to keep in sight that the more complex and dynamic the GraphSON format
will be, the more complex it will be to deserialize it and consequently more
complex to implement new GLVs. If you need to handle 4 different *combinations*
of formats (like each kind of element can have a different configuration of
detachment) instead of a constant one, it might get frustrating. GraphSON*2*
was introduced not only for the types, but also because GraphSON was too
inconsistent. Going back to a format where there can be a field "edge" in a
"g:Property" or that field could disappear to let place to another
"vertexProperty" for which the format is completely different, or the field
could simply disappear, or a field named "properties" that can have 2 different
schemas in the same enclosing entity, does seem to make things become more
inconsistent again.
I understand some times the server has to serialize more data to allow
reattachment to the parent element or Graph, however I believe that the
additional information that could be sent by the server should not modify how
the deserialization executes. I'd be advocating for a format that stays
constant but can potentially add detachment information, and in case that info
is sent by the server, it gets exposed via a extra method such as
{{Element.getAttachmentInfo()}} that the deserializer has conveniently filled
first via a "attachInfo" fields in the JSON. Then the client would be able to
do whatever it wants with that, but the deserializer does not do it itself,
because it hasn't got enough knowledge of the context to do so. Concerning
properties (Vertices'/Edges or VPs'), the field would either be empty, or
filled, in a consistent manner (and for me more consistent would mean it would
be typed as either "g:Property" or "g:VertexProperty" -> which both would have
a consistent schema).
{code}{ @type:”g:Vertex", @detach:”reference", @value: { id:1 } }{code}
Note: As explained above the "@detach" would be part of the "@value" and should
not alter the type format itself because this is not relevant information at
this stage of the deserialization. The type system is domain agnostic and
simply allows a Type to be associated with a value.
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Labels: breaking
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the
[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15709172#comment-15709172
]
Kevin Gallardo commented on TINKERPOP-1565:
---
But it wouldn't be a ReferenceXXX element that you deserialize when you use
{{getOrDefault()}} right? It would just be an empty DetachedXXX, that's the
part I struggle to understand. With the additional module, you could say
"Everything I deserialize is a DetachedXXX OR everything is ReferenceXXX". And
so according to the module used, on the serialization either everything is
lengthy and deserialized as Detached, or less lengthy and deserialized as
Reference. Also I think it would be useful (at least for me) to define what are
the fields considered sufficient for Reference elements
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703419#comment-15703419
]
Kevin Gallardo commented on TINKERPOP-1565:
---
Fair enough, if the maintenance issue is deemed not important enough, just
trying to make sure we don't make mistake if we go back to that code months
later and all that is not fresh in our heads anymore. I understand the argument
of the size efficiency/repeated data (even though I already said it was not
part of the goals of GraphSON2 otherwise GraphSON2 wouldn't look like that),
but it still bothers me though to represent the Same thing, in 2 different ways
(on one side VertexProperties as part of a Vertex, the other as a standalone
object).
Also to expand on the point "3." I mentioned earlier I hoped that the work made
on GraphSON2 would allow to get a JSON representation closer to the actual
objects as what is serialized in the Gryo protocol so that we could establish
some sort of general spec for TinkerPop serialization that would be generic
enough to apply to all the TinkerPop serialization protocols and also
facilitate the addition of new ones, BUT I'm maybe overreaching there...
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703421#comment-15703421
]
Kevin Gallardo commented on TINKERPOP-1565:
---
When you say "supports both DetachXXX and ReferenceXXX", you mean when
serializing?
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703096#comment-15703096
]
Kevin Gallardo edited comment on TINKERPOP-1565 at 11/28/16 9:30 PM:
-
"I think we should treat each element type individually"
So that's another option, as long as all do the same consistently, but why
would we do that? Is it only for the size of the payload? The way I see it I
find it useful to rely on that "cascade" because: 1. we have to rely on it
anyway for the other "non Graph structural" types - 2. it simplifies the
deserialization logic - 3. it reflects directly what the actual objects are in
the actual implementation of the serialized objects - 4. it may cause
inconsistencies otherwise, considering one would change one day the code of the
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would
need to do it there as well, so all in all, it's a code maintenance
inconvenience.
The docs say that StarGraph serialization is a format made for size efficiency,
which we had said was not to be a concern with the GraphSON2 standard
serialization. If that's not the case then fine but there is then a lot of over
things we can do to make the GraphSON2 protocol more size efficient, but that
was clearly not stated as a goal initially. For example types names are encoded
with a descriptive name as well as the "@type" and "@value" identifiers, where
all could be smaller but it was decided that we wanted to be more descriptive
here, as other future protocols can be made and be much more size efficient.
was (Author: newkek):
"I think we should treat each element type individually"
So that's another option, as long as all do the same consistently, but why
would we do that? Is it only for the size of the payload? The way I see it I
find it useful to rely on that "cascade" because: 1. we have to rely on it
anyway for the other "non Graph structural" types - 2. it simplifies the
deserialization logic - 3. it reflects directly what the actual objects are in
the actual implementation of the serialized objects - 4. it may cause
inconsistencies otherwise, considering one would change one day the code of the
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would
need to do it there as well, so all in all, it's a code maintenance
inconvenience.
The docs say that StarGraph is a format made for size efficiency, which we had
said was not to be a concern with the GraphSON2 standard serialization. If
that's not the case then fine but there is then a lot of over things we can do
to make the GraphSON2 protocol more size efficient, but that was clearly not
stated as a goal initially. For example types names are encoded with a
descriptive name as well as the "@type" and "@value" identifiers, where all
could be smaller but it was decided that we wanted to be more descriptive here,
as other future protocols can be made and be much more size efficient.
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both
[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15703096#comment-15703096
]
Kevin Gallardo commented on TINKERPOP-1565:
---
"I think we should treat each element type individually"
So that's another option, as long as all do the same consistently, but why
would we do that? Is it only for the size of the payload? The way I see it I
find it useful to rely on that "cascade" because: 1. we have to rely on it
anyway for the other "non Graph structural" types - 2. it simplifies the
deserialization logic - 3. it reflects directly what the actual objects are in
the actual implementation of the serialized objects - 4. it may cause
inconsistencies otherwise, considering one would change one day the code of the
VertexPropertyDeserializer, but do not in the VertexDeserializer, and would
need to do it there as well, so all in all, it's a code maintenance
inconvenience.
The docs say that StarGraph is a format made for size efficiency, which we had
said was not to be a concern with the GraphSON2 standard serialization. If
that's not the case then fine but there is then a lot of over things we can do
to make the GraphSON2 protocol more size efficient, but that was clearly not
stated as a goal initially. For example types names are encoded with a
descriptive name as well as the "@type" and "@value" identifiers, where all
could be smaller but it was decided that we wanted to be more descriptive here,
as other future protocols can be made and be much more size efficient.
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15702678#comment-15702678
]
Kevin Gallardo edited comment on TINKERPOP-1565 at 11/28/16 6:08 PM:
-
Also, is there a way to make the changes introduced by TINKERPOP-1520 and this
ticket in a GraphSON 2.1 version?
was (Author: newkek):
Also, isn't there a way to make the changes introduced by TINKERPOP-1520 and
this ticket in a GraphSON 2.1 version?
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1565) GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and reducing verbosity
[
https://issues.apache.org/jira/browse/TINKERPOP-1565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15691560#comment-15691560
]
Kevin Gallardo commented on TINKERPOP-1565:
---
h5. Reference and Detached Elements:
I believe that this can be nicely handled by having a GraphSONModule added to
the GraphSONMapper, that replaces all the current serializers and
deserializers, with lighter ones, that serializes *all* the Elements as
Reference Elements, and deserializes them accordingly to Reference Elements.
The GraphSON2Mapper is dynamic enough to allow to override the serializers and
deserializers for already existing types like the Graph structure types, so
you'd have all the "g:Vertex"/"g:VertexProperty" types mapped to
Vertex/VertexProperty but the implem would be Detached Elements instead of the
current Detached more heavy ones. But it sounds weird to me if we had in a same
response, different formats for the same "g:" type.
h5. Consistency with Properties
It sounds reasonable that all the classes that derive from Element, have their
properties serialized in the same format, for consistency. Since we cannot go
around having Vertices' VertexProperties being serialized with their types,
then the other Elements (VertexProperty's Properties and Edge Properties)
should follow the same path.
h5. Attaching deserialized elements
I understand the need of the parent info to reattach. However, the comment I
made was on the way it was done that could lead to problems. Assuming the code
in the PR was *creating a new* Vertex object when deserializing a
VertexProperty, based on the Vertex ID info there was in the JSON. So when a
VertexProperty is serialized on its own, that's fine. But when a VertexProperty
is serialized as part of its parent Vertex (so the JSON is "v + vp1 + vp2 +
"), then creating a new Vertex object when deserializing the VertexProperty
means that the actual parent object of the VP, and what the VP thinks its
parent is, are not the same (Java)objects
({{v.properties('name').next().element() != v}}). That's why I introduced that
mechanism in Jackson to indicate to the VP deserializer for example, if the VP
to deserialize is on its own or if it's been serialized with its parent. Hope
that's clearer
> GraphSON 2.0 updates -- supporting attachment, maintaining consistency, and
> reducing verbosity
> --
>
> Key: TINKERPOP-1565
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1565
> Project: TinkerPop
> Issue Type: Improvement
> Components: io
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.3
>
>
> GraphSON 2.0 has some issues that should be recified for its "official
> release" in 3.3.0.
> *Supporting Attachment*
> We need to make sure that every element and property can be attached back to
> the main graph.
> * For {{Vertex}}, this means that we need to have the ID encoded (CHECK).
> * For {{Edge}}, this means we need to have the out/in vertex ids encoded
> (CHECK).
> * For {{VertexProperty}}, this means we need to have the vertex ID encoded
> (ERROR).
> * For {{Property}}, this means we need to have the the element ID (vertex
> property or edge) encoded and then the subsequent vertex ID (ERROR).
> *Maintaining Consistency*
> Currently, property encoding in {{Edge}} is different than property encoding
> in {{VertexProperty}}.
> Edge -->
> {code}
> properties : {
> key : "aKey",
> value : { @type: "gProperty", @value : {"key","aKey","value",10}}
> }
> {code}
> VertexProperty-->
> {code}
> properties : {
> key : "aKey",
> value : 10
> }
> {code}
> This should be consistent.
> *Reducing Verbosity*
> We have the problem of representing both {{DetachedElements}} and
> {{ReferenceElements}}. {{DetachedElements}} contain lots of information and
> is typicaly used to ensure a data rich result set. {{ReferenceElements}}
> contain only the necessary information for attachment. I think we can support
> both representations by making certain fields "optional."
> Vertex-->
> {code}
> return new
> Vertex(json.get("id"),json.getOrDefault("label",Vertex.DEFAULT_LABEL),json.getOrDefault("properties",Collections.emptyMap()))
> {code}
> That is, lots of {{getOrDefault()}} use will make sure that when desesired,
> we only send/recv information that is needed for the particular
> computatation. E.g. as dictated by {{HaltedTraverserStrategy}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TINKERPOP-1474) API Alignment Between Java Gremlin Graph Structure and GLVs
[
https://issues.apache.org/jira/browse/TINKERPOP-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15630039#comment-15630039
]
Kevin Gallardo commented on TINKERPOP-1474:
---
It sounds important to make the distinction between what is exposed through the
API and what is the data that is actually being sent to clients. On one side
there needs to be a distinction between when the server returns an Element with
its properties and when it does not, based on the type of Traversal (OLAP or
not) and the configuration of the Gremlin server.
However, at least for the Gremlin-Java what is exposed is always the same, the
high level element interface ({{Vertex}}/{{Edge}}), which has properties
methods, and whether what the server sent was a ReferenceElement, or a
DetachedElement, the API will not change for the client. The methods to get
properties will either return the properties if they were sent, or something
empty if they weren't and that will not break users code.
It also sounds important that the GLVs follow the same path in order to achieve
the general rule of thumb [stated in the reference
doc|http://tinkerpop.apache.org/docs/current/reference/#gremlin-variants]:
bq. A strong correspondence between variants ensures that the general Gremlin
reference documentation is applicable to all variants and that users moving
between development languages can easily adopt the Gremlin variant for that
language.
The Graph structure types are already exposed through the python Gremlin
variant, so it sounds like they should be for the other GLVs and in my opinion
we should try to make it as consistent as possible.
> API Alignment Between Java Gremlin Graph Structure and GLVs
> ---
>
> Key: TINKERPOP-1474
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1474
> Project: TinkerPop
> Issue Type: Improvement
> Components: io, language-variant
>Affects Versions: 3.2.2
>Reporter: Adam Holmberg
>
> The current Java GraphSON implementation and that in the Python GLV leave
> some question about what *should* be returned from a simple traversal like
> `g.V()`.
> The java implementation presently assumes that properties could be present
> and returns a DetachedVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONSerializersV2d0.java#L420-L433
> The python implementation assumes no such thing and returns something more
> reminiscent of a ReferenceVertex:
> https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/jython/gremlin_python/structure/io/graphson.py#L238-L242
> Is the java version overreaching, and should not expect properties unless a
> step calls for them (e.g. ` g.V().valueMap()` or `g.V().values('name')`, or
> should the Python version be expanded?
> Is there something we can do to establish guidelines for this, and align
> these APIs?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1486) Improve API of RemoteConnection
Kevin Gallardo created TINKERPOP-1486:
-
Summary: Improve API of RemoteConnection
Key: TINKERPOP-1486
URL: https://issues.apache.org/jira/browse/TINKERPOP-1486
Project: TinkerPop
Issue Type: Bug
Components: io, language-variant, process
Affects Versions: 3.2.2
Reporter: Kevin Gallardo
Currently an implementor that wants to define a _RemoteConnection_
implementation must return a _RemoteTraversal_ object from the
{{RemoteConnection#submit(Bytecode)}} method.
Thus it needs to implement a specific _RemoteTraversal_ class. When
implementing a _RemoteTraversal_ we need to implement the methods {{next()}}
and {{hasNext()}}. However these methods never seem to get called. Moreover, we
need to implement the method {{nextTraverser()}} which is the one that is
actually going to get called, but the method is not abstract and it is not
natural to understand that this particular method needs to be implemented.
It seems like all the other methods of _RemoteTraversal_ are never called as
well since it is only used in _RemoteStep_, which only calls
{{nextTraverser()}}. I wonder if we could stop using the _RemoteTraversal_ and
instead have the {{submit()}} method return a simple abstract class that has:
- abstract method {{nextTraverser()}} returns _Traverser_
- abstract method {{getSideEffects()}} returns _SideEffects_
- possibly extend it later with others
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1476) TinkerGraph does not get typed with the right type name in GraphSON
Kevin Gallardo created TINKERPOP-1476:
-
Summary: TinkerGraph does not get typed with the right type name
in GraphSON
Key: TINKERPOP-1476
URL: https://issues.apache.org/jira/browse/TINKERPOP-1476
Project: TinkerPop
Issue Type: Bug
Components: io
Affects Versions: 3.2.2
Reporter: Kevin Gallardo
Priority: Minor
TinkerGraph serialized in GraphSON2 gets typed to {{gremlin:graph}} which is
not consistent with the other {{g:Xxx}} types.
For reference the code concerned is:
https://github.com/apache/tinkerpop/blob/master/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerIoRegistryV2d0.java#L124-L134
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TINKERPOP-1445) Large nested VertexProperties and Properties do not get printed well
Kevin Gallardo created TINKERPOP-1445:
-
Summary: Large nested VertexProperties and Properties do not get
printed well
Key: TINKERPOP-1445
URL: https://issues.apache.org/jira/browse/TINKERPOP-1445
Project: TinkerPop
Issue Type: Bug
Affects Versions: 3.2.2
Reporter: Kevin Gallardo
Priority: Minor
{code}
gremlin> m = ['hello':'world', 'helo':'fromtheotherside']
==>hello=world
==>helo=fromtheotherside
gremlin> graph.traversal().E().next().property('longMap', m)
==>p[longMap->{hello=world, helo=f]
{code}
Maybe the printing could be improved just to at least inform that there's more
in the value with a {{...}} or {{\[...\]}} for example.
It seems to be the {{substring()}} call in
[propertyString|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/StringFactory.java#L113].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
