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 serialize/deserialize t

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 b

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: > >> > >> > - VertexProperty and (edge) Property are implic

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 VertexProperty remark. That's o

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 Vertex

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

We need: Graph Element Vertex Edge VertexProperty Property Path TraversalExplanation TraversalMetrics Traversal (i.e. Bytecode) Traverser (object + bulk at minimum) Marko. http://marko

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 wrote: >> - It seems redundant to nest

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 used outside of the

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 is this working > > with multiple cardinalities

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

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 12:05 PM, gallardo.kev...@gm

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"< > gallardo.kev...@g

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, efficient, programming language neutral, > > lossles

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 you the >> >> format... >> > However, I don't ma

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, double, etc. given g

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 about

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 and it > works for tha

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 me

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 redundant. And to go a > > step further, I wouldn'

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 me like a self-inflicted problem because the things that > > > are typed

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

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 redundant. And to go a > step further, I wouldn't consider the types to be 'correct' because > everything that is a HashMap is r

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 you suggest would lea

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

Hi, In TINKERPOP-1278, I registered GraphSON Serializers and Deserializers for Bytecode, P, and Enums. https://github.com/apache/tinkerpop/blob/0319b3d951251ad47176ade3f19fbfdda250/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONTraversalSeriali

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 writeGrap

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

On a different subject, I read on IBM's site that GraphSON 1.0 documents "are not valid JSON documents" [1]. Is this true? I looked at one example and it did indeed look that way. It was an array of vertices but without the array notation and not separated by "," Was there a reason for this? Ple

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

If we go by the gremlin APIs: >From a client.submit(), Result [1] is only obligated to types Vertex, Edge, Path, Property, Boolean, Object, and "Numbers" (byte,short,int,long - I'll call these convenience for long; double,float - I'll call this convenience for double). Using the native java DSL,

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

Unipop uses String ids. Sqlg uses Long ids. Seems fair enough that we can compare ids as numeric by checking the graph.features() for supportsNumericIds(). One complication would be graphs that allow multiple id types. On Wed, Jul 13, 2016 at 2:07 PM, Stephen Mallette wrote: > > First, is ther

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 separat

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') ==>standardtitangraph[cassandrathrif

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

And just to be clear, I'm not necessarily disagreeing. But I think it's important to understand where and why it's necessary. For example, if I'm writing a gremlin script (string), I don't type my input numbers. It's rightly converted by the underlying architecture. (I'm guessing groovy which has

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 no

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

Hi, Sorry for the double-email. Let me add some more notes about Gremlin Bytecode. Instructions that only have primitives are easy: has name marko Instructions that have enums require typing: has T.label person Instructions that have traversals require nesting: repeat

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

Robert, thanks for joining this discussion. > I wonder if it even makes sense to type numbers according to their memory model. As objects, Byte, Short, and Integer occupy the same space. Long isn't much more. So in Java we're not saving much space. Jackson will attempt to parse in order: int, lon

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

Hello, > I wonder if it even makes sense to type numbers according to their > memory model. As objects, Byte, Short, and Integer occupy the same > space. Long isn't much more. So in Java we're not saving much space. > Jackson will attempt to parse in order: int, long, BigInt, BigDecimal. > The JS

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 t

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

[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