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.
> > > >
> > >
> >
>
