[jira] [Commented] (TINKERPOP-2011) Use NumberHelper on choose()
[
https://issues.apache.org/jira/browse/TINKERPOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551072#comment-16551072
]
ASF GitHub Bot commented on TINKERPOP-2011:
---
Github user twilmes commented on the issue:
https://github.com/apache/tinkerpop/pull/894
Code & tests LGTM.
VOTE: +1
> Use NumberHelper on choose()
>
>
> Key: TINKERPOP-2011
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2011
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> The {{choose()} step could use {{NumberHelper}} to make this easier:
> {code}
> gremlin> g.V(1).choose(values('b')).option(b,
> constant(true)).option(none,constant(false))
> ==>true
> gremlin> g.V(1).choose(values('b')).option(1,
> constant(true)).option(none,constant(false))
> ==>false
> gremlin> g.V(1).choose(values('b')).option(1 as byte,
> constant(true)).option(none,constant(false))
> ==>true
> {code}
> as discussed here:
> https://groups.google.com/d/msg/gremlin-users/4pjH7AOM72s/ohIEdABfBQAJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #894: TINKERPOP-2011 Use NumberHelper on choose()
Github user twilmes commented on the issue: https://github.com/apache/tinkerpop/pull/894 Code & tests LGTM. VOTE: +1 ---
[jira] [Commented] (TINKERPOP-2011) Use NumberHelper on choose()
[
https://issues.apache.org/jira/browse/TINKERPOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16551010#comment-16551010
]
ASF GitHub Bot commented on TINKERPOP-2011:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/894
Yep, done. I added an entry in the root `.gitignore` file and added another
`.gitignore` file in `docker/hadoop/`. The two auto-generated `Dockerfile`s
will be ignored from now on.
> Use NumberHelper on choose()
>
>
> Key: TINKERPOP-2011
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2011
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> The {{choose()} step could use {{NumberHelper}} to make this easier:
> {code}
> gremlin> g.V(1).choose(values('b')).option(b,
> constant(true)).option(none,constant(false))
> ==>true
> gremlin> g.V(1).choose(values('b')).option(1,
> constant(true)).option(none,constant(false))
> ==>false
> gremlin> g.V(1).choose(values('b')).option(1 as byte,
> constant(true)).option(none,constant(false))
> ==>true
> {code}
> as discussed here:
> https://groups.google.com/d/msg/gremlin-users/4pjH7AOM72s/ohIEdABfBQAJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #894: TINKERPOP-2011 Use NumberHelper on choose()
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/894 Yep, done. I added an entry in the root `.gitignore` file and added another `.gitignore` file in `docker/hadoop/`. The two auto-generated `Dockerfile`s will be ignored from now on. ---
[jira] [Commented] (TINKERPOP-2011) Use NumberHelper on choose()
[
https://issues.apache.org/jira/browse/TINKERPOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550952#comment-16550952
]
ASF GitHub Bot commented on TINKERPOP-2011:
---
Github user FlorianHockmann commented on the issue:
https://github.com/apache/tinkerpop/pull/894
Looks like I accidentally added that `Dockerfile`. I should have checked
more carefully what my commit added but shouldn't we prevent that from
happening again with an entry in the `.gitignore` file?
> Use NumberHelper on choose()
>
>
> Key: TINKERPOP-2011
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2011
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> The {{choose()} step could use {{NumberHelper}} to make this easier:
> {code}
> gremlin> g.V(1).choose(values('b')).option(b,
> constant(true)).option(none,constant(false))
> ==>true
> gremlin> g.V(1).choose(values('b')).option(1,
> constant(true)).option(none,constant(false))
> ==>false
> gremlin> g.V(1).choose(values('b')).option(1 as byte,
> constant(true)).option(none,constant(false))
> ==>true
> {code}
> as discussed here:
> https://groups.google.com/d/msg/gremlin-users/4pjH7AOM72s/ohIEdABfBQAJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #894: TINKERPOP-2011 Use NumberHelper on choose()
Github user FlorianHockmann commented on the issue: https://github.com/apache/tinkerpop/pull/894 Looks like I accidentally added that `Dockerfile`. I should have checked more carefully what my commit added but shouldn't we prevent that from happening again with an entry in the `.gitignore` file? ---
[jira] [Commented] (TINKERPOP-2011) Use NumberHelper on choose()
[
https://issues.apache.org/jira/browse/TINKERPOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550925#comment-16550925
]
ASF GitHub Bot commented on TINKERPOP-2011:
---
Github user dkuppitz commented on the issue:
https://github.com/apache/tinkerpop/pull/894
By the way, the `Dockerfile`, that's removed by this PR, has nothing to do
with the PR, but the file is an autogenerated file that shouldn't be in the
repository.
> Use NumberHelper on choose()
>
>
> Key: TINKERPOP-2011
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2011
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> The {{choose()} step could use {{NumberHelper}} to make this easier:
> {code}
> gremlin> g.V(1).choose(values('b')).option(b,
> constant(true)).option(none,constant(false))
> ==>true
> gremlin> g.V(1).choose(values('b')).option(1,
> constant(true)).option(none,constant(false))
> ==>false
> gremlin> g.V(1).choose(values('b')).option(1 as byte,
> constant(true)).option(none,constant(false))
> ==>true
> {code}
> as discussed here:
> https://groups.google.com/d/msg/gremlin-users/4pjH7AOM72s/ohIEdABfBQAJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #894: TINKERPOP-2011 Use NumberHelper on choose()
Github user dkuppitz commented on the issue: https://github.com/apache/tinkerpop/pull/894 By the way, the `Dockerfile`, that's removed by this PR, has nothing to do with the PR, but the file is an autogenerated file that shouldn't be in the repository. ---
[jira] [Commented] (TINKERPOP-2011) Use NumberHelper on choose()
[
https://issues.apache.org/jira/browse/TINKERPOP-2011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550918#comment-16550918
]
ASF GitHub Bot commented on TINKERPOP-2011:
---
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/894
TINKERPOP-2011 Use NumberHelper on choose()
https://issues.apache.org/jira/browse/TINKERPOP-2011
Treat numerical options in `ChooseStep` as in any other numerical
comparison (value matters, data type does not). It was a little bit trickier
than I thought as option values are only used for `HashMap` lookups and not for
direct comparisons. Anyway, I think this solution is pretty solid (and easy to
extend, should we run into any similar issues in the future).
`docker/build.sh -t -i -n` passed.
VOTE: +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-2011
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/894.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #894
commit f7d628e344ff132fca9c4460521a40231aa8acce
Author: Daniel Kuppitz
Date: 2018-07-18T19:34:16Z
TINKERPOP-2011 Treat numerical options in `ChooseStep` as in any other
numerical comparison (value matters, data type does not).
> Use NumberHelper on choose()
>
>
> Key: TINKERPOP-2011
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2011
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> The {{choose()} step could use {{NumberHelper}} to make this easier:
> {code}
> gremlin> g.V(1).choose(values('b')).option(b,
> constant(true)).option(none,constant(false))
> ==>true
> gremlin> g.V(1).choose(values('b')).option(1,
> constant(true)).option(none,constant(false))
> ==>false
> gremlin> g.V(1).choose(values('b')).option(1 as byte,
> constant(true)).option(none,constant(false))
> ==>true
> {code}
> as discussed here:
> https://groups.google.com/d/msg/gremlin-users/4pjH7AOM72s/ohIEdABfBQAJ
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #894: TINKERPOP-2011 Use NumberHelper on choose()
GitHub user dkuppitz opened a pull request: https://github.com/apache/tinkerpop/pull/894 TINKERPOP-2011 Use NumberHelper on choose() https://issues.apache.org/jira/browse/TINKERPOP-2011 Treat numerical options in `ChooseStep` as in any other numerical comparison (value matters, data type does not). It was a little bit trickier than I thought as option values are only used for `HashMap` lookups and not for direct comparisons. Anyway, I think this solution is pretty solid (and easy to extend, should we run into any similar issues in the future). `docker/build.sh -t -i -n` passed. VOTE: +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-2011 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/894.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #894 commit f7d628e344ff132fca9c4460521a40231aa8acce Author: Daniel Kuppitz Date: 2018-07-18T19:34:16Z TINKERPOP-2011 Treat numerical options in `ChooseStep` as in any other numerical comparison (value matters, data type does not). ---
[jira] [Commented] (TINKERPOP-1996) Introduce read() and write() steps
[ https://issues.apache.org/jira/browse/TINKERPOP-1996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550910#comment-16550910 ] ASF GitHub Bot commented on TINKERPOP-1996: --- GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/893 TINKERPOP-1996 io() https://issues.apache.org/jira/browse/TINKERPOP-1996 Introduces `io()` with full support for GLVs and both OLAP and OLTP. There's a bit too much to type here to fully describe this - please take a look at the documentation in the PR as it goes into the details. All tests pass with `docker/build.sh -t -n -i` VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1996 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/893.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #893 commit ec1d05f74fa875e4a07699dc89c3d1956aab586f Author: Stephen Mallette Date: 2018-06-29T19:04:17Z TINKERPOP-1996 Introduce read() and write() steps commit 0785090f67ff88a834f77c7181a69594049c65ea Author: Stephen Mallette Date: 2018-07-10T16:21:52Z TINKERPOP-1996 Have the basics of OLAP read()/write() steps working This is still fairly skeletal at this point. Just trying to make sure things work properly before building read()/write() out fully. commit ff2773a5ef1eff379cb5f3b809d4677ff64a076d Author: Stephen Mallette Date: 2018-07-10T16:55:06Z TINKERPOP-1996 Minor refactoring of Reading/Writing and javadoc commit d99909c4e19fcb3ec3b8a8c94eb054a4332ad219 Author: Stephen Mallette Date: 2018-07-10T18:53:52Z TINKERPOP-1996 read()/write() api changes for return type No more weird Map status return for read() and write(). Both just work like a terminator and self iterate to return nothing. commit 767d65b9d54f1774b13cc5a61db711268f213ff1 Author: Stephen Mallette Date: 2018-07-11T14:20:39Z TINKERPOP-1996 Made read()/write() terminator steps Without this approach the with() operator couldn't be used because the traversal would already be iterated on the call to read() and write(). In this way read() and write() are both terminators and modulators at the same time. commit d181563d24a401ac6550e06d86d78b12a8f16f51 Author: Stephen Mallette Date: 2018-07-11T14:36:11Z TINKERPOP-1996 Added some javadoc and code formatting commit 13e552b289b5266fcb418baaf2ae90626f6055c4 Author: Stephen Mallette Date: 2018-07-11T19:40:39Z TINKERPOP-1996 Added with() options for io() Included GraphReader and GraphWriter detection and added tests commit be9db8de6a9d2abb5222b7ab5b9326049060e85a Author: Stephen Mallette Date: 2018-07-12T12:17:56Z TINKERPOP-1996 none() doesn't need to be removed in HadoopIoStrategy Not sure why this was there in the first place. Removing it not allows Hadoop integration tests to pass, but seems to have no real effect on existing operations. commit 328737a371f8a2040d02f9c2dbb06d049ce3c881 Author: Stephen Mallette Date: 2018-07-12T15:19:10Z TINKERPOP-1996 Added IO to imports and javadoc fixes commit ae796378e07925f9385f3ec65c10022b59aab8b5 Author: Stephen Mallette Date: 2018-07-12T18:33:03Z TINKERPOP-1996 Deprecated Graph.io() and related infrastructure. commit 9e4da0149247a50277e2a468b0becf892426ce2e Author: Stephen Mallette Date: 2018-07-13T15:37:02Z TINKERPOP-1996 Fixed a bad method call for Configuring steps commit bd275a7ffa4f0d04634c830aa4f7577375c7944c Author: Stephen Mallette Date: 2018-07-13T15:37:21Z TINKERPOP-1996 Removed OptOuts for read()/write() tests Not necessary because existing checks ignore these. For read() you can't write to a HadoopGraph directly (i.e. create vertices/edges) and for write() (and technically read()) it is ignored as it requires a GraphComputer to work. commit f148e9331a945e0f4f707ea937b610e5902701c7 Author: Stephen Mallette Date: 2018-07-13T19:17:17Z TINKERPOP-1996 Got read/write() tests running for OLAP Introduced new Graph.Features to provider better separation between graph mutation features and graph loading features - they are two different things as demonstrated by io(). Fixed HadoopIoStep/Strategy so that they properly handle the different input/output format types expected. commit 576649fd5456f6390bf9481d01438a7e78db083e Author: Stephen Mallette Date: 2018-07-13T19:22:43Z TINKERPOP-1996 Updated changelog commit 62175c228b77bdbda96c11015f2974828df8f3aa Author: Stephen Mallette Date: 2018-07-13T21:31:46Z TINKERPOP-1996 Added docs for io() Killed all the old IO documentation that utilized the GraphReader/Writer classes d
[GitHub] tinkerpop pull request #893: TINKERPOP-1996 io()
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/893 TINKERPOP-1996 io() https://issues.apache.org/jira/browse/TINKERPOP-1996 Introduces `io()` with full support for GLVs and both OLAP and OLTP. There's a bit too much to type here to fully describe this - please take a look at the documentation in the PR as it goes into the details. All tests pass with `docker/build.sh -t -n -i` VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1996 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/893.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #893 commit ec1d05f74fa875e4a07699dc89c3d1956aab586f Author: Stephen Mallette Date: 2018-06-29T19:04:17Z TINKERPOP-1996 Introduce read() and write() steps commit 0785090f67ff88a834f77c7181a69594049c65ea Author: Stephen Mallette Date: 2018-07-10T16:21:52Z TINKERPOP-1996 Have the basics of OLAP read()/write() steps working This is still fairly skeletal at this point. Just trying to make sure things work properly before building read()/write() out fully. commit ff2773a5ef1eff379cb5f3b809d4677ff64a076d Author: Stephen Mallette Date: 2018-07-10T16:55:06Z TINKERPOP-1996 Minor refactoring of Reading/Writing and javadoc commit d99909c4e19fcb3ec3b8a8c94eb054a4332ad219 Author: Stephen Mallette Date: 2018-07-10T18:53:52Z TINKERPOP-1996 read()/write() api changes for return type No more weird Map status return for read() and write(). Both just work like a terminator and self iterate to return nothing. commit 767d65b9d54f1774b13cc5a61db711268f213ff1 Author: Stephen Mallette Date: 2018-07-11T14:20:39Z TINKERPOP-1996 Made read()/write() terminator steps Without this approach the with() operator couldn't be used because the traversal would already be iterated on the call to read() and write(). In this way read() and write() are both terminators and modulators at the same time. commit d181563d24a401ac6550e06d86d78b12a8f16f51 Author: Stephen Mallette Date: 2018-07-11T14:36:11Z TINKERPOP-1996 Added some javadoc and code formatting commit 13e552b289b5266fcb418baaf2ae90626f6055c4 Author: Stephen Mallette Date: 2018-07-11T19:40:39Z TINKERPOP-1996 Added with() options for io() Included GraphReader and GraphWriter detection and added tests commit be9db8de6a9d2abb5222b7ab5b9326049060e85a Author: Stephen Mallette Date: 2018-07-12T12:17:56Z TINKERPOP-1996 none() doesn't need to be removed in HadoopIoStrategy Not sure why this was there in the first place. Removing it not allows Hadoop integration tests to pass, but seems to have no real effect on existing operations. commit 328737a371f8a2040d02f9c2dbb06d049ce3c881 Author: Stephen Mallette Date: 2018-07-12T15:19:10Z TINKERPOP-1996 Added IO to imports and javadoc fixes commit ae796378e07925f9385f3ec65c10022b59aab8b5 Author: Stephen Mallette Date: 2018-07-12T18:33:03Z TINKERPOP-1996 Deprecated Graph.io() and related infrastructure. commit 9e4da0149247a50277e2a468b0becf892426ce2e Author: Stephen Mallette Date: 2018-07-13T15:37:02Z TINKERPOP-1996 Fixed a bad method call for Configuring steps commit bd275a7ffa4f0d04634c830aa4f7577375c7944c Author: Stephen Mallette Date: 2018-07-13T15:37:21Z TINKERPOP-1996 Removed OptOuts for read()/write() tests Not necessary because existing checks ignore these. For read() you can't write to a HadoopGraph directly (i.e. create vertices/edges) and for write() (and technically read()) it is ignored as it requires a GraphComputer to work. commit f148e9331a945e0f4f707ea937b610e5902701c7 Author: Stephen Mallette Date: 2018-07-13T19:17:17Z TINKERPOP-1996 Got read/write() tests running for OLAP Introduced new Graph.Features to provider better separation between graph mutation features and graph loading features - they are two different things as demonstrated by io(). Fixed HadoopIoStep/Strategy so that they properly handle the different input/output format types expected. commit 576649fd5456f6390bf9481d01438a7e78db083e Author: Stephen Mallette Date: 2018-07-13T19:22:43Z TINKERPOP-1996 Updated changelog commit 62175c228b77bdbda96c11015f2974828df8f3aa Author: Stephen Mallette Date: 2018-07-13T21:31:46Z TINKERPOP-1996 Added docs for io() Killed all the old IO documentation that utilized the GraphReader/Writer classes directly as well as the Graph.io() method that is now deprecated. commit 6d05805ada657bcb3f50a60aa0c313c29d4611bb Author: Stephen Mallette Date: 2018-07-14T10:23:54Z TINKERPOP-1996 Moved IoStep implementations to sideEffect package These steps really a
[jira] [Commented] (TINKERPOP-2006) GraphML serialization invalid if a vertex and edge have similar named property
[
https://issues.apache.org/jira/browse/TINKERPOP-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550832#comment-16550832
]
ASF GitHub Bot commented on TINKERPOP-2006:
---
Github user twilmes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/891#discussion_r204067177
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriter.java
---
@@ -218,20 +220,33 @@ private void writeTypes(final Map
identifiedVertexKeyTypes,
final Map
identifiedEdgeKeyTypes,
final XMLStreamWriter writer) throws
XMLStreamException {
//
-final Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection edgeKeySet =
getEdgeKeysAndNormalizeIfRequired(identifiedEdgeKeyTypes);
+// in case vertex and edge may have the same attribute name, the
key id in graphml have to be different
+intersection = CollectionUtils.intersection(vertexKeySet,
edgeKeySet);
+// speeding-up later checks
+if(intersection.isEmpty()){
+intersection = null;
+}
for (String key : vertexKeySet) {
writer.writeStartElement(GraphMLTokens.KEY);
-writer.writeAttribute(GraphMLTokens.ID, key);
+if(intersection != null && intersection.contains(key)){
--- End diff --
Maybe here and below you could set a key variable once, something like:
```
String keyVal = key;
if (!intersection.isEmpty() && intersection.contains(key)) {
keyVal = key.concat(GraphMLTokens.VERTEX_SUFFIX)
}
writer.writeAttribute(GraphMLTokens.ID, key);
```
> GraphML serialization invalid if a vertex and edge have similar named property
> --
>
> Key: TINKERPOP-2006
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2006
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.3
>Reporter: Svante Schubert
>Priority: Trivial
>
> I have created a graph using the Tinkerpop Graph and required for Gephi
> visualization a property called color on edges and vertices to be coloured.
> The current gremlin-core serialization creates the following two key elements
> in GraphML
>
>
> the id attribute is an internal name, but have to be different.
> I would suggest a patch to check for an intersection of the edge & vertices
> keys and add for those keys an additional differentiating letter like:
>
>
>
> Going to provide a pullrequest on GitHub.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #891: TINKERPOP-2006 - Fix for valid GraphML export w...
Github user twilmes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/891#discussion_r204067177
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriter.java
---
@@ -218,20 +220,33 @@ private void writeTypes(final Map
identifiedVertexKeyTypes,
final Map
identifiedEdgeKeyTypes,
final XMLStreamWriter writer) throws
XMLStreamException {
//
-final Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection edgeKeySet =
getEdgeKeysAndNormalizeIfRequired(identifiedEdgeKeyTypes);
+// in case vertex and edge may have the same attribute name, the
key id in graphml have to be different
+intersection = CollectionUtils.intersection(vertexKeySet,
edgeKeySet);
+// speeding-up later checks
+if(intersection.isEmpty()){
+intersection = null;
+}
for (String key : vertexKeySet) {
writer.writeStartElement(GraphMLTokens.KEY);
-writer.writeAttribute(GraphMLTokens.ID, key);
+if(intersection != null && intersection.contains(key)){
--- End diff --
Maybe here and below you could set a key variable once, something like:
```
String keyVal = key;
if (!intersection.isEmpty() && intersection.contains(key)) {
keyVal = key.concat(GraphMLTokens.VERTEX_SUFFIX)
}
writer.writeAttribute(GraphMLTokens.ID, key);
```
---
[jira] [Commented] (TINKERPOP-2006) GraphML serialization invalid if a vertex and edge have similar named property
[
https://issues.apache.org/jira/browse/TINKERPOP-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550828#comment-16550828
]
ASF GitHub Bot commented on TINKERPOP-2006:
---
Github user twilmes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/891#discussion_r204065865
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriter.java
---
@@ -218,20 +220,33 @@ private void writeTypes(final Map
identifiedVertexKeyTypes,
final Map
identifiedEdgeKeyTypes,
final XMLStreamWriter writer) throws
XMLStreamException {
//
-final Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection edgeKeySet =
getEdgeKeysAndNormalizeIfRequired(identifiedEdgeKeyTypes);
+// in case vertex and edge may have the same attribute name, the
key id in graphml have to be different
+intersection = CollectionUtils.intersection(vertexKeySet,
edgeKeySet);
+// speeding-up later checks
+if(intersection.isEmpty()){
--- End diff --
I can see what you're doing for the `null` check but I'm wondering if it's
worth it versus just initializing the intersection to an empty set at the start
to make the code a bit simpler. Did you do some performance comparison and
identify that the null check approach was a lot faster?
> GraphML serialization invalid if a vertex and edge have similar named property
> --
>
> Key: TINKERPOP-2006
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2006
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.3
>Reporter: Svante Schubert
>Priority: Trivial
>
> I have created a graph using the Tinkerpop Graph and required for Gephi
> visualization a property called color on edges and vertices to be coloured.
> The current gremlin-core serialization creates the following two key elements
> in GraphML
>
>
> the id attribute is an internal name, but have to be different.
> I would suggest a patch to check for an intersection of the edge & vertices
> keys and add for those keys an additional differentiating letter like:
>
>
>
> Going to provide a pullrequest on GitHub.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #891: TINKERPOP-2006 - Fix for valid GraphML export w...
Github user twilmes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/891#discussion_r204065865
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriter.java
---
@@ -218,20 +220,33 @@ private void writeTypes(final Map
identifiedVertexKeyTypes,
final Map
identifiedEdgeKeyTypes,
final XMLStreamWriter writer) throws
XMLStreamException {
//
-final Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection edgeKeySet =
getEdgeKeysAndNormalizeIfRequired(identifiedEdgeKeyTypes);
+// in case vertex and edge may have the same attribute name, the
key id in graphml have to be different
+intersection = CollectionUtils.intersection(vertexKeySet,
edgeKeySet);
+// speeding-up later checks
+if(intersection.isEmpty()){
--- End diff --
I can see what you're doing for the `null` check but I'm wondering if it's
worth it versus just initializing the intersection to an empty set at the start
to make the code a bit simpler. Did you do some performance comparison and
identify that the null check approach was a lot faster?
---
[jira] [Commented] (TINKERPOP-2006) GraphML serialization invalid if a vertex and edge have similar named property
[
https://issues.apache.org/jira/browse/TINKERPOP-2006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550825#comment-16550825
]
ASF GitHub Bot commented on TINKERPOP-2006:
---
Github user twilmes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/891#discussion_r204065136
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriter.java
---
@@ -218,20 +220,33 @@ private void writeTypes(final Map
identifiedVertexKeyTypes,
final Map
identifiedEdgeKeyTypes,
final XMLStreamWriter writer) throws
XMLStreamException {
//
-final Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
--- End diff --
Could these still be made `final`?
> GraphML serialization invalid if a vertex and edge have similar named property
> --
>
> Key: TINKERPOP-2006
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2006
> Project: TinkerPop
> Issue Type: Bug
> Components: io
>Affects Versions: 3.3.3
>Reporter: Svante Schubert
>Priority: Trivial
>
> I have created a graph using the Tinkerpop Graph and required for Gephi
> visualization a property called color on edges and vertices to be coloured.
> The current gremlin-core serialization creates the following two key elements
> in GraphML
>
>
> the id attribute is an internal name, but have to be different.
> I would suggest a patch to check for an intersection of the edge & vertices
> keys and add for those keys an additional differentiating letter like:
>
>
>
> Going to provide a pullrequest on GitHub.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #891: TINKERPOP-2006 - Fix for valid GraphML export w...
Github user twilmes commented on a diff in the pull request:
https://github.com/apache/tinkerpop/pull/891#discussion_r204065136
--- Diff:
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/graphml/GraphMLWriter.java
---
@@ -218,20 +220,33 @@ private void writeTypes(final Map
identifiedVertexKeyTypes,
final Map
identifiedEdgeKeyTypes,
final XMLStreamWriter writer) throws
XMLStreamException {
//
-final Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
+Collection vertexKeySet =
getVertexKeysAndNormalizeIfRequired(identifiedVertexKeyTypes);
--- End diff --
Could these still be made `final`?
---
[GitHub] tinkerpop pull request #890: Expose Pick in module.exports
Github user asfgit closed the pull request at: https://github.com/apache/tinkerpop/pull/890 ---
[jira] [Closed] (TINKERPOP-2009) Pick.any and Pick.none should be exposed in Gremlin-JavaScript
[ https://issues.apache.org/jira/browse/TINKERPOP-2009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jorge Bay closed TINKERPOP-2009. Resolution: Fixed > Pick.any and Pick.none should be exposed in Gremlin-JavaScript > --- > > Key: TINKERPOP-2009 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2009 > Project: TinkerPop > Issue Type: Bug > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Jorge Bay >Priority: Major > Fix For: 3.4.0, 3.3.4, 3.2.10 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[GitHub] tinkerpop issue #890: Expose Pick in module.exports
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/890 Cherry picked and landed in c324002c7d2184b87ef1e90067c318ebf727311f (`tp32`, `tp33` and `master`). Thanks @arings! ---
[jira] [Commented] (TINKERPOP-2012) Target .NET Standard 2.0 for Gremlin.Net
[
https://issues.apache.org/jira/browse/TINKERPOP-2012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16550376#comment-16550376
]
Jorge Bay commented on TINKERPOP-2012:
--
.NET Standard 2.0 can be comfortable for users, and I understand the push from
MS engineers to try to move developers to focus on a more complete API (as 2.0
is).
I think we should still support .NET Standard 1.x, as .NET Core 1.0 and 1.1 are
the latest LTS releases: https://www.microsoft.com/net/support/policy
We could add a .NET Standard 2.0 target on all active branches and then drop
1.x support after 1.1 EOL (mid next year).
> Target .NET Standard 2.0 for Gremlin.Net
>
>
> Key: TINKERPOP-2012
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2012
> Project: TinkerPop
> Issue Type: Improvement
> Components: dotnet
>Affects Versions: 3.3.3, 3.2.9
>Reporter: Florian Hockmann
>Priority: Major
>
> The general recommendation from the .NET team is now to target .NET Standard
> 2.0 instead of the lowest version possible (which was the recommendation
> until .NET Standard 2.0):
> {quote}I know we said target The lowest netstandard but we really want
> everyone to re-baseline at netstandard 2.0. At the very least add a
> netstandard 2.0 target.
> {quote}
> [Source|https://twitter.com/davidfowl/status/1008453902058917888]
> Apart from an increased API surface compared to .NET Standard 1.x, .NET
> Standard reduces the dependency graph of libraries. Right now the
> dependencies for Gremlin.Net look like this:
> *.NETStandard 1.3*
> * NETStandard.Library (>= 1.6.1)
> * Newtonsoft.Json (>= 9.0.1)
> * System.Net.WebSockets (>= 4.3.0)
> * System.Net.WebSockets.Client (>= 4.3.0)
> * System.Reflection.TypeExtensions (>= 4.3.0)
> With .NET Standard 2.0, the only dependency left should be Newtonsoft.Json.
> We have to decide whether we want to upgrade from .NET Standard 1.3 or to
> just add .NET Standard 2.0 as an additional target framework. Upgrading would
> mean that consuming applications would need slightly newer framework versions
> (e.g. .NET Framework 4.6.1 instead of 4.6 or Mono 5.4 instead of 4.6).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
