You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@tinkerpop.apache.org by sp...@apache.org on 2018/03/23 11:08:28 UTC
[1/3] tinkerpop git commit: update index.asciidoc
Repository: tinkerpop
Updated Branches:
refs/heads/master ead0edaf4 -> 0996419ef
update index.asciidoc
Add design doc for reference based object model
Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/ba915458
Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/ba915458
Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/ba915458
Branch: refs/heads/master
Commit: ba915458a3d4121a55d563dfc8267417574c8f94
Parents: ead0eda
Author: Ashwini Singh <30...@users.noreply.github.com>
Authored: Thu Mar 22 15:42:43 2018 -0700
Committer: GitHub <no...@github.com>
Committed: Thu Mar 22 15:42:43 2018 -0700
----------------------------------------------------------------------
docs/src/dev/future/index.asciidoc | 20 +++++++++++++++++++-
1 file changed, 19 insertions(+), 1 deletion(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/ba915458/docs/src/dev/future/index.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/future/index.asciidoc b/docs/src/dev/future/index.asciidoc
index d37f3e1..9d3c49e 100644
--- a/docs/src/dev/future/index.asciidoc
+++ b/docs/src/dev/future/index.asciidoc
@@ -152,8 +152,26 @@ essentially build a subgraph which is merged into the primary graph. That subgra
Build it locally then submit it remotely and have the server sort out the merging. It's perhaps the most natural way
to load data. With "Gremlinito" you then get the added power of being able to traverse a local subgraph.
+
+== Uniform object model for GraphSON response for client drivers
+On TINKERPOP-1909, it was suggested that we are going to use refence (id/label) based object model. And, the direction is
+move towards more tidy object model contracts going forward. Reference model definitely provides big performance improvements
+especially with multi-property vertices/edges. One thing that we can consider is to provide a configurable object
+model. Enabling users to configure the object model (OutputFormat) as server settings (Exposing server setting is
+being discussed here TINKERPOP-1636). There will three types of output format.
+
+* Reference: includes id and label
+
+* GraphSONCompact: object reference along with properties
+
+* GraphSON: object reference, properties and edge details(inE/outE).
+=== Comments
+This will enable the clients model based on their needs and avoid multiple query if they are sure what is expected
+from a gremlin query. If we need more details like edges/property as part of response, we can override the server
+configuration as part of the gremlin request arguments as hint.
+
== Testing Framework
Consider a testing framework based on the Gherkin tests from 3.x and a `gremlin-test` parent module for all the test
framework modules that will potentially be needed. In 3.x, we found situation where having test modules beyond
-`gremlin-test` would have been helpful, so a parent module that held all those would probably be smart.
\ No newline at end of file
+`gremlin-test` would have been helpful, so a parent module that held all those would probably be smart.
[2/3] tinkerpop git commit: fix format
Posted by sp...@apache.org.
fix format
fixing format
Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/79dc2cdf
Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/79dc2cdf
Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/79dc2cdf
Branch: refs/heads/master
Commit: 79dc2cdf157a4df688a68f80100e6aecefcc28b9
Parents: ba91545
Author: Ashwini Singh <30...@users.noreply.github.com>
Authored: Thu Mar 22 15:43:44 2018 -0700
Committer: GitHub <no...@github.com>
Committed: Thu Mar 22 15:43:44 2018 -0700
----------------------------------------------------------------------
docs/src/dev/future/index.asciidoc | 1 +
1 file changed, 1 insertion(+)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/79dc2cdf/docs/src/dev/future/index.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/future/index.asciidoc b/docs/src/dev/future/index.asciidoc
index 9d3c49e..ee3c1a4 100644
--- a/docs/src/dev/future/index.asciidoc
+++ b/docs/src/dev/future/index.asciidoc
@@ -165,6 +165,7 @@ being discussed here TINKERPOP-1636). There will three types of output format.
* GraphSONCompact: object reference along with properties
* GraphSON: object reference, properties and edge details(inE/outE).
+
=== Comments
This will enable the clients model based on their needs and avoid multiple query if they are sure what is expected
from a gremlin query. If we need more details like edges/property as part of response, we can override the server
[3/3] tinkerpop git commit: Added a section on Serialization
Posted by sp...@apache.org.
Added a section on Serialization
Instituted the "comment" system, included a comment on the newly added Uninform Object Model, and added some minor cleanup. CTR
Project: http://git-wip-us.apache.org/repos/asf/tinkerpop/repo
Commit: http://git-wip-us.apache.org/repos/asf/tinkerpop/commit/0996419e
Tree: http://git-wip-us.apache.org/repos/asf/tinkerpop/tree/0996419e
Diff: http://git-wip-us.apache.org/repos/asf/tinkerpop/diff/0996419e
Branch: refs/heads/master
Commit: 0996419ef67a487c7607918a216e8a35485eea0f
Parents: 79dc2cd
Author: Stephen Mallette <sp...@genoprime.com>
Authored: Fri Mar 23 07:07:14 2018 -0400
Committer: Stephen Mallette <sp...@genoprime.com>
Committed: Fri Mar 23 07:08:10 2018 -0400
----------------------------------------------------------------------
docs/src/dev/future/index.asciidoc | 61 ++++++++++++++++++++++++++-------
1 file changed, 48 insertions(+), 13 deletions(-)
----------------------------------------------------------------------
http://git-wip-us.apache.org/repos/asf/tinkerpop/blob/0996419e/docs/src/dev/future/index.asciidoc
----------------------------------------------------------------------
diff --git a/docs/src/dev/future/index.asciidoc b/docs/src/dev/future/index.asciidoc
index ee3c1a4..11115cf 100644
--- a/docs/src/dev/future/index.asciidoc
+++ b/docs/src/dev/future/index.asciidoc
@@ -31,6 +31,11 @@ There is no particular layout or style to this document. Simple bullet points, o
sentences, or fully structured document headers and content are all acceptable. The main point is to capture ideas
for future consideration when 4.x becomes the agenda of the day for The TinkerPop.
+If adding comments sections, please "sign" comments with initials and reference those initials here:
+
+* *spm* - Stephen Mallette
+* *as* - Ashwini Singh
+
image:tp4-think.png[]
== The Main Features
@@ -109,7 +114,7 @@ g.V(v).values(‘name’)
This split into two Graph APIs will enables us to make a hard boundary between what the provider (vendor) needs to
implement and what the user (developer) gets to access.
-=== Comments
+=== Comments [spm]
There is a question mark next to `ReferenceGraph.tx()` - Transactions are a bit of an open question for future versions
of TinkerPop and likely deserve their own section in this document. The model used for last three version of TinkerPop
@@ -126,6 +131,7 @@ problem for TinkerGraph which relied on `io()` for flushing to file storage. Thi
link:https://issues.apache.org/jira/browse/TINKERPOP-892[TINKERPOP-892]
* `tx()` - as discussed in the earlier paragraph
+[[gremlin-language-subset]]
== Gremlin Language Subset
On link:https://issues.apache.org/jira/browse/TINKERPOP-1417[TINKERPOP-1417], it was suggested that we "Create a
@@ -144,7 +150,7 @@ Thus:
* path, simplePath, cyclicPath
* groupCount, sum, group, count, max, min, etc. (reducing barriers)
-=== Comments
+=== Comments [spm]
This has an interesting potential impact on GLVs because "Little Gremlin" could be implemented within them for
client-side traversals over remote subgraphs, where the subgraph is like a remote transaction. All graph mutations
@@ -152,24 +158,53 @@ essentially build a subgraph which is merged into the primary graph. That subgra
Build it locally then submit it remotely and have the server sort out the merging. It's perhaps the most natural way
to load data. With "Gremlinito" you then get the added power of being able to traverse a local subgraph.
+[[serialization]]
+== Serialization
+
+Have we yet found the appropriate serialization model? We didn't have it in 2.x at all. In 3.x we went with a use case
+based approach that made a lot of sense in the first few releases of 3.x, but the use cases couldn't have conceived
+of what was to come with the development of GLVs. GLVs rendered Gryo, the decided "network option" from the use cases,
+to be pretty useless given that it is of the JVM only and GraphSON has gone through three versions now trying to find
+the appropriate format to cover the various features we've attempted to support. While GraphSON 3.0 seems to have met
+the mark for supporting our needs, it seems bloated with Java types and doesn't perform terribly well in some cases.
+
+An ideal serialization format would be:
-== Uniform object model for GraphSON response for client drivers
-On TINKERPOP-1909, it was suggested that we are going to use refence (id/label) based object model. And, the direction is
-move towards more tidy object model contracts going forward. Reference model definitely provides big performance improvements
-especially with multi-property vertices/edges. One thing that we can consider is to provide a configurable object
-model. Enabling users to configure the object model (OutputFormat) as server settings (Exposing server setting is
-being discussed here TINKERPOP-1636). There will three types of output format.
+* Compact for network transport
+* Human readable (which competes with "compact" at some level)
+* Language agnostic
+* Exposes a small set of types that makes the format easy to maintain and test
+* Extendable or perhaps built in such a way that graph providers could coerce their types to and from the types
+that TinkerPop exposes
+* Upgrade friendly so that it is possible to easily detect the version of a format and have the system act
+transparently so as to avoid the heavy configuration that users currently have to do to be sure their versions of
+TinkerPop and their version of their serializers align
-* Reference: includes id and label
+== Uniform Object Model
-* GraphSONCompact: object reference along with properties
+On link:https://issues.apache.org/jira/browse/TINKERPOP-1909[TINKERPOP-1909], it was suggested that we are going to
+use reference (id/label) based object model. And, the direction is move towards more tidy object model contracts going
+forward. Reference model definitely provides big performance improvements especially with multi-property
+vertices/edges. One thing that we can consider is to provide a configurable object model. Enabling users to
+configure the object model (OutputFormat) as server settings (Exposing server setting is being discussed here
+link:https://issues.apache.org/jira/browse/TINKERPOP-1636[TINKERPOP-1636]). There will three types of output format.
-* GraphSON: object reference, properties and edge details(inE/outE).
+* Reference: includes id and label
+* GraphSONCompact: object reference along with properties
+* GraphSON: object reference, properties and edge details(inE/outE).
+
+=== Comments [as]
-=== Comments
This will enable the clients model based on their needs and avoid multiple query if they are sure what is expected
from a gremlin query. If we need more details like edges/property as part of response, we can override the server
-configuration as part of the gremlin request arguments as hint.
+configuration as part of the gremlin request arguments as hint.
+
+=== Comments [spm]
+
+A more full object model may be necessary as we consider implementing the options of the
+<<gremlin-language-subset,Gremlin Language Subset>>. A more robust object model, or at least the option to open up a
+more robust object model, could be necessary to support features there. We should also consider that the future is not
+necessarily a GraphSON format and could be something else as described in the <<serialization,Serialization>> section.
== Testing Framework