Hi,
In TINKERPOP-1278, I registered GraphSON Serializers and Deserializers for
Bytecode, P, and Enums.
https://github.com/apache/tinkerpop/blob/0319b3d951251ad47176ade3f19fbccccfdda250/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONTraversalSerializers.java
<https://github.com/apache/tinkerpop/blob/0319b3d951251ad47176ade3f19fbccccfdda250/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONTraversalSerializers.java>
https://github.com/apache/tinkerpop/blob/0319b3d951251ad47176ade3f19fbccccfdda250/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L126-L142
<https://github.com/apache/tinkerpop/blob/0319b3d951251ad47176ade3f19fbccccfdda250/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphson/GraphSONModule.java#L126-L142>
Now you can do this:
https://gist.github.com/okram/1e9b407670b51e5f5fb6b85b2b9a6caa
<https://gist.github.com/okram/1e9b407670b51e5f5fb6b85b2b9a6caa>
TADA!,
Marko.
http://markorodriguez.com
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 the Gremlin traversal API, its more about provider schemas.
has(“someNumber”,12L) vs. has(“someNumber”,12).
> On Jul 13, 2016, at 3:29 PM, Robert Dale <robd...@gmail.com> wrote:
>
> 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, looks like Traversal.next() [2] would
> return Vertex, Edge, Property, Map, Object, (extends) Number.
> Probably Boolean. Maybe a VertexProperty? Possibly others but hard to
> tell since it's all generics. Please correct me where I'm wrong.
>
> In other words, IMHO the GLV really has no obligation to preserve or
> maintain any other specific types. (Don't get me wrong, it's very
> convenient, but not required.) This is analogous to other types of
> drivers. For instance, JDBC has no idea what java type you actually
> want. It does know how it's stored in the database but otherwise it
> has convenience methods for numbers and other things. While it's
> common to map objects to tables 1:1, it's really up to the caller to
> be aware of and call for the expected type.
>
> I think it's the responsibility of the graph-database driver to be
> able to convert types appropriately to the underlying system. And we
> do see this behavior with existing graph implementations. Take for
> example UUID. I don't specify the type to gremlin script. It's a
> string. The graph-driver knows to convert that to a UUID if it's
> schema is configured as such. If there wasn't a schema, that's fine,
> it will just be stored as a string. And someone who doesn't set a
> schema, obviously doesn't care how it's stored.
>
> For automatic and strong type conversion, one would use a Object Graph
> Mapper (like an ORM, e.g. Hibernate) at a layer above the GLV. This
> thing would introspect objects and see that, hey, it wants a Short
> instead of the default long, or it wants a UUID instead of a String, I
> should convert those things because I'm so handy!
>
> So getting out of the type conversion game makes your life a little
> easier. Maybe it puts more pressure on graph providers to do
> conversion but also to potentially provide GraphSON codecs for any
> non-gremlin-supported types.
>
> I don't think I have anything more to say on the subject. To be
> honest, I have no skin in the game. I don't see myself directly
> consuming this. Ultimately you guys need to decide what works for you
> and your use cases.
>
> 1.
> http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/driver/Result.html
> 2.
> http://tinkerpop.apache.org/javadocs/current/full/org/apache/tinkerpop/gremlin/process/traversal/Traversal.html
>
>
> On Wed, Jul 13, 2016 at 3:56 PM, Jason Plurad <plur...@gmail.com> wrote:
>> 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 <spmalle...@gmail.com>
>> wrote:
>>
>>>> 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 separate
>>> discussion.
>>>
>>>> Neo4j via NeoGraph appears to do the right thing for vertex IDs and
>>> properties.
>>> It treats all types, primitive or object, from byte to long, double, float
>>> as numbers.
>>>
>>> Perhaps we could take a stronger stance on this in the test cases? Does
>>> anyone know what graphs this would impact besides Titan and TinkerGraph (I
>>> suspect DSE Graph, but not 100% sure)?
>>>
>>>
>>>
>>> On Wed, Jul 13, 2016 at 1:49 PM, Robert Dale <robd...@gmail.com> wrote:
>>>
>>>> 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
>>>> get crap out. So designers should be aware of these types of pitfalls.
>>>> Neo4j via NeoGraph appears to do the right thing for vertex IDs and
>>>> properties. It treats all types, primitive or object, from byte to
>>>> long, double, float as numbers. This is pretty standard behavior in
>>>> SQL, JDBC drivers, and other NoSQL technologies.
>>>>
>>>>
>>>>
>>>> On Wed, Jul 13, 2016 at 11:30 AM, Stephen Mallette <spmalle...@gmail.com
>>>>
>>>> wrote:
>>>>> 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[cassandrathrift:[127.0.0.1]]
>>>>> gremlin> graph.addVertex("n",100D)
>>>>> ==>v[4288]
>>>>> gremlin> graph.traversal().V().has('n',100f)
>>>>> gremlin> graph.traversal().V().has('n',100d)
>>>>> ==>v[4288]
>>>>>
>>>>> This kind of problem has caused trouble for years and years in
>>> TinkerPop
>>>>> and allowing the type to be embedded seemed like a good solution. Of
>>>>> course, you bring up a good point about javascript - to this point
>>> we've
>>>>> relied on JS devs to conform to java/groovy types by forcing conversion
>>>> in
>>>>> their gremlin scripts or configuring their graphs to avoid use of types
>>>>> that would produce these kinds of ambiguous results.
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 13, 2016 at 9:51 AM, Robert Dale <robd...@gmail.com>
>>> wrote:
>>>>>
>>>>>> 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 enhanced number support). Also, if a
>>>>>> GLV is submitting typed numbers, how would that work? For example, in
>>>>>> Javascript?
>>>>>>
>>>>>> On Wed, Jul 13, 2016 at 9:16 AM, Robert Dale <robd...@gmail.com>
>>> wrote:
>>>>>>> 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 not only, brain-damaged languages where 5 != 5 !=
>>>>>>> 5. In Java, number objects must be coerced into like form for
>>>>>>> comparison. The other ID managers do this coercion. Saner languages
>>>>>>> do this under the covers.
>>>>>>>
>>>>>>> On Wed, Jul 13, 2016 at 8:56 AM, Stephen Mallette <
>>>> spmalle...@gmail.com>
>>>>>> wrote:
>>>>>>>> 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, 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?
>>>>>>>>
>>>>>>>> If the intended numeric type isn't preserved, weird things can
>>> happen
>>>>>> with
>>>>>>>> graphs that have a schema (like Titan/DSE). Even TinkerGraph using
>>>> the
>>>>>>>> default ID manager will not be happy if you try to do a lookup of
>>>> Long
>>>>>>>> identifiers with an Integer:
>>>>>>>>
>>>>>>>> gremlin> graph = TinkerFactory.createModern()
>>>>>>>> ==>tinkergraph[vertices:6 edges:6]
>>>>>>>> gremlin> graph.vertices(1)
>>>>>>>> ==>v[1]
>>>>>>>> gremlin> graph.vertices(1L)
>>>>>>>> gremlin>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Jul 13, 2016 at 8:17 AM, Robert Dale <robd...@gmail.com>
>>>> 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 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
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Robert Dale
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Robert Dale
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Robert Dale
>>>>
>>>
>
>
>
> --
> Robert Dale
