Hi,
Just to check, will it be configurable, returning a ReferenceVertex or
the Vertex together with its properties?
Thanks
Pieter
On 19/05/2016 16:39, Stephen Mallette wrote:
> Ok - that's what i thought - just wanted to be certain I didn't
> misunderstand you. I'm fine with that. Thanks.
>
> On Thu, May 19, 2016 at 10:18 AM, Dylan Millikin <dylan.milli...@gmail.com>
> wrote:
>
>> When to switch default behavior. At this point there's no question about
>> adding this feature. It's definitely a requirement. Once the feature is in
>> place we can perhaps discuss it more or put it to a vote (which behavior to
>> default on what version)?
>>
>> On Thu, May 19, 2016 at 10:15 AM, Stephen Mallette <spmalle...@gmail.com>
>> wrote:
>>
>>> sorry - what aspect of this do you want to have "sit" for later review?
>>>
>>> On Thu, May 19, 2016 at 10:10 AM, Dylan Millikin <
>> dylan.milli...@gmail.com
>>> wrote:
>>>
>>>> Ah yeah the lack of consistency between OLTP and OLAP -is- an issue.
>>> You're
>>>> right lets let this sit and review it at a later time.
>>>>
>>>>
>>>> On Thu, May 19, 2016 at 9:58 AM, Stephen Mallette <
>> spmalle...@gmail.com>
>>>> wrote:
>>>>
>>>>> So, first and foremost, yes we would still have both, so nothing goes
>>>> away
>>>>> - so that's good.
>>>>>
>>>>> As for the rest, I understand. When you query a document in Mongo,
>> you
>>>> get
>>>>> the whole document for example. Most folks would expect that, coming
>>> from
>>>>> other systems I guess. The problem is I don't think we can go the
>> other
>>>>> direction to make it work consistently between olap and oltp which is
>>> its
>>>>> own worry. We would get the same confusion when someone issues their
>>>> query
>>>>> against spark and gets a ReferenceVertex rather than DetachedVertex.
>>> I'm
>>>>> not tied to the idea of making ReferenceVertex the default in Gremlin
>>>>> Server for 3.3.x - i guess we can put that up for debate when the
>> time
>>>>> comes.
>>>>>
>>>>> On Thu, May 19, 2016 at 9:20 AM, Dylan Millikin <
>>>> dylan.milli...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hey,
>>>>>>
>>>>>> I'm a little torn here. On one side it's good to have the option of
>>>>>> returning a ReferenceVertex, which is currently really complicated
>> to
>>>> do.
>>>>>> On the other hand this new behavior is far from intuitive and has
>>> some
>>>>>> difficultly surmountable issues.
>>>>>>
>>>>>> If I'm understanding you correctly both behaviors would still live
>>>>> through,
>>>>>> we would just switch the default mode right? I would like to debate
>>>>> whether
>>>>>> or not this new behavior should be default (I don't really know
>>> where I
>>>>>> stand but just for the sake of being thorough).
>>>>>>
>>>>>> Barring the actual issues this introduces (as I'm pretty sure it's
>>> only
>>>>>> going to concern very few people and they can use whatever conf).
>>>> People
>>>>>> coming from the SQL world and who already have trouble adjusting to
>>>>> gremlin
>>>>>> will find this counter-intuitive. After all these people couldn't
>>> care
>>>>> less
>>>>>> about ReferenceVertex, on the other hand it's very natural to
>> query a
>>>>>> vertex and get it's info. Not to mention that when handling a
>> vertex
>>>>>> directly or using a traversal the ways of getting the properties
>> are
>>>>>> different and not very consistent.
>>>>>>
>>>>>> Again, I don't really know where I stand on this, I just wanted to
>> be
>>>>>> thorough.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>> On Wed, May 18, 2016 at 4:04 PM, Stephen Mallette <
>>>> spmalle...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> I'll try to keep this simple, as serialization tends to be
>> anything
>>>> but
>>>>>>> simple....
>>>>>>>
>>>>>>> Forgetting GraphML which has its own rules, GraphSON and Gryo are
>>> the
>>>>> two
>>>>>>> key serialization modules that we have in IO. We use these for
>>> both
>>>>>>> serialization to disk as well as serialization over the network
>> in
>>>>>> Gremlin
>>>>>>> Server. If you issue a request like:
>>>>>>>
>>>>>>> g.V()
>>>>>>>
>>>>>>> it returns vertices obviously. For both Gryo and GraphSON, those
>>>>> vertices
>>>>>>> are converted to DetachedVertex which includes the properties of
>>> the
>>>>>>> Vertex. This can be tremendously expensive, especially if the
>> graph
>>>>>>> supports multi-properties.
>>>>>>>
>>>>>>> I think that Gremlin Server should take a hint from OLAP in
>>> relation
>>>> to
>>>>>>> this issue. With OLAP, a Vertex is converted to a ReferenceVertex
>>>> where
>>>>>> we
>>>>>>> only get the element identifier passed around.
>>>>>>>
>>>>>>> gremlin> graph =
>>>>> GraphFactory.open('conf/hadoop/hadoop-gryo.properties')
>>>>>>> ==>hadoopgraph[gryoinputformat->gryooutputformat]
>>>>>>> gremlin> g = graph.traversal().withComputer(SparkGraphComputer)
>>>>>>>
>>>> ==>graphtraversalsource[hadoopgraph[gryoinputformat->gryooutputformat],
>>>>>>> sparkgraphcomputer]
>>>>>>> gremlin> l = g.V().toList();[]
>>>>>>> gremlin> l[0].class
>>>>>>> ==>class
>>>>>>>
>>> org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex
>>>>>>> If you want more information, it is up to you to issue your query
>>> to
>>>>>>> request that information - for example:
>>>>>>>
>>>>>>> g.V().valueMap(true)
>>>>>>>
>>>>>>> I think Gremlin Server should work in the same fashion (i.e.
>>> return a
>>>>>>> ReferenceVertex when a Vertex is serialized over the network).
>> It
>>>>> would
>>>>>>> ease up on serialization overhead and force users to be more
>>> explicit
>>>>>> about
>>>>>>> the data that they want which would prevent unnecessary
>> performance
>>>>>>> surprises. This change might also be nice for the efficiency of
>>>>>>> RemoteGraph/Connection implementations.
>>>>>>>
>>>>>>> This has bothered me for a while, but we carried over the pattern
>>>> from
>>>>>>> TinkerPop 2.x of sending back properties and I've been concerned
>>>> about
>>>>>>> introducing a break in trying to improve that. I dug into it
>> more
>>>>> today
>>>>>>> and my analysis seems to indicate that this change can occur
>>> without
>>>>>>> breaking all the code that's currently out there. I think that we
>>>> could
>>>>>>> keep the existing serialization model and simply add in the
>>>>>> ReferenceVertex
>>>>>>> approach as a configuration option for 3.2.1 and then make it the
>>>>> default
>>>>>>> for 3.3.x.
>>>>>>>
>>>>>>> If there are no objections in the next 72 hours (Saturday, May
>> 21,
>>>>> 2016,
>>>>>>> 4pm EST) I'll assume lazy consensus and move forward.
>>>>>>>
