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 type is at the same level than the data itself, whether the > container is an Array or an Object > https://github.com/apache/tinkerpop/pull/351#issuecomment-231351653 What exactly are the inconsistencies? What is the problem in determining an array or object? This is a natural JSON array (or list): [] This is a natural JSON object: {} Type at the object level is a common pattern and supported feature of Jackson. Also, GeoJSON would be a natural fit as it also stores 'type' at the object level. Titan supports GeoJSON currently. I wonder if it would make sense to promote geometry to gremlin. We should probably start documenting a table of supported types. (If there is one, please provide link) 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 JSON JSR uses only BigDecimal. Some non-jvm languages don't even have this concept. Does anything in gremlin actually require this? I'm thinking that this is only going to be relevant at the domain model level. This way json native numbers can be used and not need typing. Additionally, I think that all things that will be typed should always be typed. For the use cases of injesting a saved graph from a file, it can probably be assumed that the top-level objects are vertices since the graph is vertex-centric and everything else follows naturally. I'm not entirely sure what is required for submitting traversals to gremlin server from GLV. However, if this is used for the results from gremlin server then the results could start with any one of path, vertex, edge, property, vertex property, etc. So you'll need that type data there. -- Robert Dale On Tue, Jul 12, 2016 at 8:35 AM, Marko Rodriguez <okramma...@gmail.com> wrote: > 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<String,Class> for typecasting > accordingly. > 3. This would make GraphSON 2.0 perfect for Bytecode serialization in > TINKERPOP-1278. > 4. I think that if a Vertex, Edge, etc. doesn’t have properties, > outV, etc. then don’t even have those fields in the representation. > 5. Most of the serialization back and forth will be ReferenceXXX > elements and thus, don’t create more Maps/lists for no reason. — less chars. > > For me, my interests with this work is all about a language agnostic way of > sending Gremlin traversal bytecode between different languages. This work is > exactly what I am looking for. > > Thanks, > Marko. > > http://markorodriguez.com > > > >> On Jul 9, 2016, at 9:48 AM, Stephen Mallette <spmalle...@gmail.com> 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 that purpose (ever more so with 2.0). Given some discussion on >> the GraphSON 2.0 PR driven a bit by Robert Dale: >> >> https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389 >> >> I wonder if we shouldn't consider another IO format that has Gremlin >> Server/GLVs in mind. At this point I'm not suggesting anything specific - >> I'm just hanging the idea out for further discussion and brain storming. >> Thoughts? > -- Robert Dale
