Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-19 22:28 (+0100), Marko Rodriguez wrote: > Hi, > > However, in general we just need an “object mapper pattern.” For instance: > > For any JSON object { } that has a @type field, the @type value maps to a > deserializer. Thus, while we need to be able to

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hi, However, in general we just need an “object mapper pattern.” For instance: For any JSON object { } that has a @type field, the @type value maps to a deserializer. Thus, while we need to be able to serialize/deserialize the standard Vertex/Edge/VertexProperty/etc. the representation should

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

ah - sorry - didn't follow that. that makes sense to me. inVLabel and outVLabel are kinda awkward. +1 from me on that one. On Tue, Jul 19, 2016 at 3:23 PM, Robert Dale wrote: > On Tue, Jul 19, 2016 at 3:13 PM, Stephen Mallette > wrote: > >> > >> > -

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On Tue, Jul 19, 2016 at 3:13 PM, Stephen Mallette wrote: >> >> > - VertexProperty and (edge) Property are implicit types. I don't know >> > if this is ok. Could they ever be used outside of their parents where >> > they would need to be typed? >> >> I agree with the

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

> > > - VertexProperty and (edge) Property are implicit types. I don't know > > if this is ok. Could they ever be used outside of their parents where > > they would need to be typed? > > I agree with the VertexProperty remark. That's one last question I wanted > to solve, if we go for typing

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

There's also Path that can be returned from a query. It looks like GraphSON 1.0 handles this today in the REST API but it's not typed as a path. On Tue, Jul 19, 2016 at 2:14 PM, gallardo.kev...@gmail.com wrote: > > > On 2016-07-19 18:02 (+0100), Robert Dale

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-19 18:02 (+0100), Robert Dale wrote: > - It seems redundant to nest a vertex or edge inside a type-value > object and is inconsistent with a VertexProperty. > - VertexProperty and (edge) Property are implicit types. I don't know > if this is ok. Could they ever be

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-19 17:47 (+0100), Stephen Mallette wrote: > it should - properties are a Map of Lists of Property values. > > On Tue, Jul 19, 2016 at 12:45 PM, Dylan Millikin > wrote: > > > Quick question which is probably handled automatically but

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

- It seems redundant to nest a vertex or edge inside a type-value object and is inconsistent with a VertexProperty. - VertexProperty and (edge) Property are implicit types. I don't know if this is ok. Could they ever be used outside of their parents where they would need to be typed? - Edges: -

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

it should - properties are a Map of Lists of Property values. On Tue, Jul 19, 2016 at 12:45 PM, Dylan Millikin wrote: > Quick question which is probably handled automatically but is this working > with multiple cardinalities on properties? > > On Tue, Jul 19, 2016 at

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Quick question which is probably handled automatically but is this working with multiple cardinalities on properties? On Tue, Jul 19, 2016 at 12:05 PM, gallardo.kev...@gmail.com < gallardo.kev...@gmail.com> wrote: > > > On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com"< >

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-15 16:25 (+0100), "gallardo.kev...@gmail.com" wrote: > > > On 2016-07-09 16:48 (+0100), Stephen Mallette wrote: > > With all the work on GLVs and the recent work on GraphSON 2.0, I think it's > > important that we have a solid,

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On Mon, Jul 18, 2016 at 6:29 AM, gallardo.kev...@gmail.com wrote: > > On 2016-07-15 21:32 (+0100), Robert Dale wrote: >> Responding to Marko and Kevin... [...] >> >> Kevin wrote: >> >> Correct, these types weren't relevant... I only wanted to show

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-15 21:32 (+0100), Robert Dale wrote: > Responding to Marko and Kevin... > > Marko wrote: > > SIDENOTE: This serves as a foundation for when we move to GraphSON 2.0. In > > terms of numbers, I think, unfortunately, we have to stick with int32, > > int64, float,

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Responding to Marko and Kevin... Marko wrote: > SIDENOTE: This serves as a foundation for when we move to GraphSON 2.0. In > terms of numbers, I think, unfortunately, we have to stick with int32, int64, > float, double, etc. given graph database providers and their type systems. > Its not

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-09 16:48 (+0100), Stephen Mallette wrote: > With all the work on GLVs and the recent work on GraphSON 2.0, I think it's > important that we have a solid, efficient, programming language neutral, > lossless serialization format. Right now that format is GraphSON

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hello, > How would you define that format in a general way ? Like what I did when > saying > "- untyped : value > - typed : {"@type", "typeName", "value" : value}" > > Just trying your point better. > Also what are the downsides you see with the format suggested above ? This makes sense to

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-15 15:52 (+0100), "gallardo.kev...@gmail.com" wrote: > > > On 2016-07-15 14:44 (+0100), Robert Dale wrote: > > It looks to me like a self-inflicted problem because the things that > > are typed are already native to json so it's

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-15 16:07 (+0100), "gallardo.kev...@gmail.com" wrote: > > > On 2016-07-15 15:52 (+0100), > "gallardo.kev...@gmail.com" wrote: > > > > > > On 2016-07-15 14:44 (+0100), Robert Dale wrote: > > > It looks to

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

It looks to me like a self-inflicted problem because the things that are typed are already native to json so it's redundant. And to go a step further, I wouldn't consider the types to be 'correct' because everything that is a HashMap is really a Vertex, Edge, or Property. On Thu, Jul 14, 2016 at

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

On 2016-07-13 13:17 (+0100), Robert Dale wrote: > Marko, I agree that empty object properties should not be represented. > I think if you saw that in an example then it was probably for > demonstration purposes. > > Kevin, can you expand on this comment: > > > the format

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hi, In TINKERPOP-1278, I registered GraphSON Serializers and Deserializers for Bytecode, P, and Enums.

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

i'll answer your second email first about GraphSON because it's shorter and i know the answer without too much thought (i'll need to take some time to think on the other). So the answer to "is this true?" is yes and no. The "yes" part is related to the fact that I believe that by default

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

> First, is there a wiki that we can keep updated with decisions or at least decision points? I know there's an old wiki, but is there/will there be a new wiki? No - we don't have a wiki. Design decisions tend to get trapped in the mailing list (or JIRA) which isn't so good. Maybe that's a

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

First, is there a wiki that we can keep updated with decisions or at least decision points? I know there's an old wiki, but is there/will there be a new wiki? Stephen, IMO, that's still bad behavior. That says to me a number is not a number. But, yes, schemaless does allow one to put crap in and

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hi, Here is a toy class I just made that converts Bytecode to “GraphSON2.0.” I believe it covers everything! (save I didn’t blow out the Number section): https://gist.github.com/okram/908b73b24e8db48f1006124942a900b1 The

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Marko, the namespacing idea seems smart. Robert, I think other graphs have similar behavior to TinkerGraph's default. In Titan, the absence of a schema (default, obviously) produces this: gremlin> graph = TitanFactory.open('conf/titan-cassandra-es.properties')

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hi, Stephen. I think that's a bad example. You may recall I brought up that issue in the forum. However, it's actually attributed to the default ID manager of ANY (for historical) which I think is a really bad default (and reason) because it only leads to confusion. Java is one of the few, if

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Marko, I agree that empty object properties should not be represented. I think if you saw that in an example then it was probably for demonstration purposes. Kevin, can you expand on this comment: > the format you suggest would lead to the same inconsistencies as in GraphSON > 1.0. > Since the

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

Hi, I’m not following this PR too closely so what I might be saying is a already known/argued against/etc. 1. I think we should go with Robert Dale’s proposal of int32, int64, Vertex, uuid, etc. instead of Java class names. 2. In Java we then have a Map for

[DISCUSS] New IO format for GLVs/Gremlin Server

With all the work on GLVs and the recent work on GraphSON 2.0, I think it's important that we have a solid, efficient, programming language neutral, lossless serialization format. Right now that format is GraphSON and it works for that purpose (ever more so with 2.0). Given some discussion on the