Re: [DISCUSS] Proposal to add transaction support to TinkerGraph.
Hi all, I'm working on transactions implementation and I would like to discuss testing of this feature. Currently available options for tests in TinkerPop: 1. Unit tests. For development I wrote bunch of unit tests for the newly introduced TinkerTransactionGraph because they are easier to make and much more convenient to debug. However, these tests are very complicated to be reused by other providers. 2. Gherkin tests. This is the best option for providers to test some features. However, the current implementation does not support many of the abilities needed to test transactions, for example multi-step tests and multi-threaded tests. The ideal solution would be to add such features, but unfortunately it takes a lot of time and effort. For basic checks of TinkerTransactionGraph existing Gherkin tests are already used. 3. Integration tests. We have 2 kinds of integration tests in `gremlin-test` a) process tests are mirror of Gherkin tests with some small differences. b) structure tests are probably the best candidate to use for TinkerTransactionGraph. There is already a set of tests for transactions in TransactionTest and I can add more cases there. These tests will be used in a similar way to TinkerGraphStructureStandardTest. 4. Gremlin Server tests. I think these tests have a different responsibility. 5. GLV tests. All GLV's already have transaction tests and we can extend them to use TinkerTransactionGraph at server-side. To summarize I suggest using structure tests to verify transaction implementation. Regards, Valentyn On Wed, May 10, 2023 at 2:59 PM Valentyn Kahamlyk < valent...@bitquilltech.com> wrote: > Hi all, > > I opened PR with a detailed proposal for transaction implementation: > https://github.com/apache/tinkerpop/pull/2054. > > Regards, Valentyn > > On Mon, Feb 27, 2023 at 1:22 PM Valentyn Kahamlyk < > valent...@bitquilltech.com> wrote: > >> Hi all, >> >> Now, if you need to use transactions in tinkerpop, the only solution is >> to use the Neo4J plugin. Unfortunately, this plugin has not been updated >> for a long time and is only compatible with Neo4J version 3.4, which >> reached end of life in March, 2020. >> >> I propose to implement native transaction support in TinkerGraph. >> >> The most interesting question to discuss is the level of isolation in SQL >> 92 terms. There are 5 options to choose from: `Read uncommitted`, `Read >> committed`, `Repeatable read`, `Snapshot` and `Serializable`. >> >> In terms of balancing complexity of implementation and functionality, I >> think the most optimal option is `Read committed` or `Repeatable read`. >> >> I hope to implement `Read committed`, it is enough to add versions to the >> Vertices and Edges, add list of updated Elements in Graph. >> Write lock can be Vertex-level and Edge-level. >> >> Regards, Valentyn >> >
[jira] [Commented] (TINKERPOP-2959) Allow the grammar to support parameters
[
https://issues.apache.org/jira/browse/TINKERPOP-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733253#comment-17733253
]
ASF GitHub Bot commented on TINKERPOP-2959:
---
Cole-Greer commented on PR #2094:
URL: https://github.com/apache/tinkerpop/pull/2094#issuecomment-1593795756
Thanks for putting this all together Stephen. I'm a big fan of anything
which reduces the gap between gremlin-lang and gremlin-groovy. This is a bit
out of my wheelhouse but I took a good look through the new grammar and tests.
Other than the one question I posted above about mapEntry, it all looks good to
me.
> Allow the grammar to support parameters
> ---
>
> Key: TINKERPOP-2959
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2959
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.6.4
>Reporter: Stephen Mallette
>Priority: Major
>
> Allow the grammar to support parameters similar to how the groovy engine does
> like, {{g.inject(x,y,z)}}. Doing this will make it easier for a transition
> away from the groovy engine as a lot of Gremlin in the world today uses
> parameters. The grammar may have to come with some limitations though as
> groovy is wide open in terms of what can be treated as a variable. Probably
> going to keep parameters tied to primitives, collections and tokens/enums
> like {{Order}} and {{Scope}}. Collections themselves will not contain
> parameters and things like a {{Traversal}} or {{P}} cannot be treated as one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2959) Allow the grammar to support parameters
[
https://issues.apache.org/jira/browse/TINKERPOP-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733251#comment-17733251
]
ASF GitHub Bot commented on TINKERPOP-2959:
---
Cole-Greer commented on code in PR #2094:
URL: https://github.com/apache/tinkerpop/pull/2094#discussion_r1231588579
##
gremlin-language/src/main/antlr4/Gremlin.g4:
##
@@ -1403,7 +1521,7 @@ genericLiteralMap
| LBRACK mapEntry (COMMA mapEntry)* RBRACK
;
-// allow builds of Map that sorta make sense in the Gremlin context
+// allow builds of Map that sorta make sense in the Gremlin context.
mapEntry
: NEW COLON genericLiteral // explicit for [new: true] - if we had other
keywords like that maybe we'd group them up?
| (LPAREN stringLiteral RPAREN | stringLiteral) COLON genericLiteral
Review Comment:
I believe that for each of these, the value part of the mapEntry should be a
`genericLiteralArgument` instead of just a `genericLiteral`. Just checked in
console and groovy allows passing variables as the value in maps.
> Allow the grammar to support parameters
> ---
>
> Key: TINKERPOP-2959
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2959
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.6.4
>Reporter: Stephen Mallette
>Priority: Major
>
> Allow the grammar to support parameters similar to how the groovy engine does
> like, {{g.inject(x,y,z)}}. Doing this will make it easier for a transition
> away from the groovy engine as a lot of Gremlin in the world today uses
> parameters. The grammar may have to come with some limitations though as
> groovy is wide open in terms of what can be treated as a variable. Probably
> going to keep parameters tied to primitives, collections and tokens/enums
> like {{Order}} and {{Scope}}. Collections themselves will not contain
> parameters and things like a {{Traversal}} or {{P}} cannot be treated as one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2958) ScheduledExecutorService for timeouts are never cancelled
[ https://issues.apache.org/jira/browse/TINKERPOP-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733244#comment-17733244 ] ASF GitHub Bot commented on TINKERPOP-2958: --- xiazcy commented on PR #2090: URL: https://github.com/apache/tinkerpop/pull/2090#issuecomment-1593739096 LGTM, VOTE +1 > ScheduledExecutorService for timeouts are never cancelled > - > > Key: TINKERPOP-2958 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2958 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.6.3, 3.6.4 >Reporter: Lyndon Bauto >Assignee: Lyndon Bauto >Priority: Major > > A scheduled task was added to timeout a request in the future. > > This task is not cancelled when the request is completed before the timeout. > With a long timeout, this can lead to extreme memory usage (~1 GB growth per > minute on my laptop with my graph implementation). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2959) Allow the grammar to support parameters
[
https://issues.apache.org/jira/browse/TINKERPOP-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733238#comment-17733238
]
ASF GitHub Bot commented on TINKERPOP-2959:
---
vkagamlyk commented on code in PR #2094:
URL: https://github.com/apache/tinkerpop/pull/2094#discussion_r1231535172
##
gremlin-core/src/test/java/org/apache/tinkerpop/gremlin/language/grammar/ArgumentVisitorTest.java:
##
@@ -0,0 +1,260 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tinkerpop.gremlin.language.grammar;
+
+import org.antlr.v4.runtime.CharStreams;
+import org.antlr.v4.runtime.CommonTokenStream;
+import org.apache.tinkerpop.gremlin.process.traversal.IO;
+import org.apache.tinkerpop.gremlin.process.traversal.Merge;
+import org.apache.tinkerpop.gremlin.process.traversal.Operator;
+import org.apache.tinkerpop.gremlin.process.traversal.Order;
+import org.apache.tinkerpop.gremlin.process.traversal.P;
+import org.apache.tinkerpop.gremlin.process.traversal.Pop;
+import org.apache.tinkerpop.gremlin.process.traversal.SackFunctions;
+import org.apache.tinkerpop.gremlin.process.traversal.Scope;
+import
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.GraphTraversalSource;
+import org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__;
+import org.apache.tinkerpop.gremlin.structure.Column;
+import org.apache.tinkerpop.gremlin.structure.Direction;
+import org.apache.tinkerpop.gremlin.structure.T;
+import org.apache.tinkerpop.gremlin.structure.Vertex;
+import org.apache.tinkerpop.gremlin.structure.VertexProperty;
+import org.apache.tinkerpop.gremlin.structure.util.ElementHelper;
+import org.apache.tinkerpop.gremlin.structure.util.empty.EmptyGraph;
+import org.apache.tinkerpop.gremlin.structure.util.reference.ReferenceVertex;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+
+import java.util.Arrays;
+import java.util.Date;
+import java.util.List;
+import java.util.function.Supplier;
+
+import static
org.apache.tinkerpop.gremlin.process.traversal.AnonymousTraversalSource.traversal;
+import static org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.has;
+import static
org.apache.tinkerpop.gremlin.process.traversal.dsl.graph.__.hasLabel;
+import static org.hamcrest.MatcherAssert.assertThat;
+import static org.hamcrest.core.IsInstanceOf.instanceOf;
+import static org.junit.Assert.assertEquals;
+import static org.junit.Assert.fail;
+
+@RunWith(Parameterized.class)
+public class ArgumentVisitorTest {
+@Parameterized.Parameter(value = 0)
+public Class clazz;
+
+@Parameterized.Parameter(value = 1)
+public String script;
+
+@Parameterized.Parameter(value = 2)
+public Object expected;
+
+@Parameterized.Parameter(value = 3)
+public GremlinAntlrToJava antlrToLanguage;
+
+private static final GraphTraversalSource g =
EmptyGraph.instance().traversal();
+
+private static final Date now = new Date();
+
+@Parameterized.Parameters(name = "{0}")
+public static Iterable generateTestParameters() {
+return Arrays.asList(new Object[][]{
+{Boolean.class, "x", new VariableResolverException("x"),
createAntlr(VariableResolver.NoVariableResolver.instance())},
+{Boolean.class, "true", true, createAntlr(new
VariableResolver.DefaultVariableResolver(ElementHelper.asMap("x", true)))},
+{Boolean.class, "false", false, createAntlr(new
VariableResolver.DefaultVariableResolver(ElementHelper.asMap("x", true)))},
+{Boolean.class, "x", true, createAntlr(new
VariableResolver.DefaultVariableResolver(ElementHelper.asMap("x", true)))},
+{Integer.class, "x", new VariableResolverException("x"),
createAntlr(VariableResolver.NoVariableResolver.instance())},
+{Integer.class, "0", 0, createAntlr(new
VariableResolver.DefaultVariableResolver(ElementHelper.asMap("x", 100)))},
+{Integer.class, "0i", 0, createAntlr(new
VariableResolver.DefaultVariableResolver(ElementHelper.asMap("x", 100)))},
+{Integer.class, "0L", 0L, createAntlr(new
[jira] [Commented] (TINKERPOP-2959) Allow the grammar to support parameters
[
https://issues.apache.org/jira/browse/TINKERPOP-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733233#comment-17733233
]
ASF GitHub Bot commented on TINKERPOP-2959:
---
xiazcy commented on PR #2094:
URL: https://github.com/apache/tinkerpop/pull/2094#issuecomment-1593701729
This feature definitely opens up improvement opportunties. I'm not too
familiar with many of the technical details, but on a high level the change
looks good. I also like how the grammar variables are more intuitive now. VOTE
+1
> Allow the grammar to support parameters
> ---
>
> Key: TINKERPOP-2959
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2959
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.6.4
>Reporter: Stephen Mallette
>Priority: Major
>
> Allow the grammar to support parameters similar to how the groovy engine does
> like, {{g.inject(x,y,z)}}. Doing this will make it easier for a transition
> away from the groovy engine as a lot of Gremlin in the world today uses
> parameters. The grammar may have to come with some limitations though as
> groovy is wide open in terms of what can be treated as a variable. Probably
> going to keep parameters tied to primitives, collections and tokens/enums
> like {{Order}} and {{Scope}}. Collections themselves will not contain
> parameters and things like a {{Traversal}} or {{P}} cannot be treated as one.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2871) Borrowed count can be wildly incorrect
[ https://issues.apache.org/jira/browse/TINKERPOP-2871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733223#comment-17733223 ] Ken Hu commented on TINKERPOP-2871: --- I believe there were some changes to the driver in 3.6 that reduces the impact of this issue for that branch. I will have to do some testing to confirm this. > Borrowed count can be wildly incorrect > -- > > Key: TINKERPOP-2871 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2871 > Project: TinkerPop > Issue Type: Bug > Components: driver >Affects Versions: 3.5.5 >Reporter: Stephen Mallette >Priority: Critical > > It doesn't seem like it affects the algorithm for borrowing/closing > connections in the pool but the borrowed counter can sometimes reach wildly > large numbers. it shows up in the log and is confusing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2959) Allow the grammar to support parameters
[
https://issues.apache.org/jira/browse/TINKERPOP-2959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733218#comment-17733218
]
ASF GitHub Bot commented on TINKERPOP-2959:
---
vkagamlyk commented on code in PR #2094:
URL: https://github.com/apache/tinkerpop/pull/2094#discussion_r1231504873
##
gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/language/grammar/ArgumentVisitor.java:
##
@@ -0,0 +1,420 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.tinkerpop.gremlin.language.grammar;
+
+import org.apache.tinkerpop.gremlin.process.traversal.Merge;
+import org.apache.tinkerpop.gremlin.process.traversal.Operator;
+import org.apache.tinkerpop.gremlin.process.traversal.Order;
+import org.apache.tinkerpop.gremlin.process.traversal.Pop;
+import org.apache.tinkerpop.gremlin.process.traversal.SackFunctions;
+import org.apache.tinkerpop.gremlin.process.traversal.Scope;
+import org.apache.tinkerpop.gremlin.structure.Column;
+import org.apache.tinkerpop.gremlin.structure.Direction;
+import org.apache.tinkerpop.gremlin.structure.T;
+import org.apache.tinkerpop.gremlin.structure.Vertex;
+import org.apache.tinkerpop.gremlin.structure.VertexProperty;
+
+import java.lang.reflect.Array;
+import java.util.Collection;
+import java.util.Comparator;
+import java.util.Map;
+import java.util.function.Function;
+
+public class ArgumentVisitor extends DefaultGremlinBaseVisitor {
+
+private final VariableResolver resolver;
+
+private final GremlinAntlrToJava antlr;
+
+public ArgumentVisitor(final VariableResolver resolver, final
GremlinAntlrToJava antlr) {
+this.resolver = resolver;
+this.antlr = antlr;
+}
+
+/**
+ * Wrapper to visit function for boolean.
+ */
+public boolean parseBoolean(final GremlinParser.BooleanArgumentContext
ctx) {
+return (boolean) visitBooleanArgument(ctx);
+}
+
+/**
+ * Wrapper to visit function for integer types.
+ */
+public Number parseNumber(final GremlinParser.IntegerArgumentContext ctx) {
+return (Number) visitIntegerArgument(ctx);
+}
+
+/**
+ * Wrapper to visit function for float types.
+ */
+public Number parseNumber(final GremlinParser.FloatArgumentContext ctx) {
+return (Number) visitFloatArgument(ctx);
+}
+
+/**
+ * Wrapper to visit function for string types.
+ */
+public String parseString(final GremlinParser.StringArgumentContext ctx) {
+return (String) visitStringArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for object types.
+ */
+public Object parseObject(final
GremlinParser.GenericLiteralArgumentContext ctx) {
+return visitGenericLiteralArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for {@link Direction} types.
+ */
+public Direction parseDirection(final
GremlinParser.TraversalDirectionArgumentContext ctx) {
+return (Direction) visitTraversalDirectionArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for {@link Vertex} types.
+ */
+public Vertex parseVertex(final
GremlinParser.StructureVertexArgumentContext ctx) {
+return (Vertex) visitStructureVertexArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for {@link Order} types.
+ */
+public Order parseOrder(final GremlinParser.TraversalOrderArgumentContext
ctx) {
+return (Order) visitTraversalOrderArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for {@link Scope} types.
+ */
+public Scope parseScope(final GremlinParser.TraversalScopeArgumentContext
ctx) {
+return (Scope) visitTraversalScopeArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for {@link T} types.
+ */
+public T parseT(final GremlinParser.TraversalTokenArgumentContext ctx) {
+return (T) visitTraversalTokenArgument(ctx);
+}
+
+/**
+ * Wrapper for visit function for {@link VertexProperty.Cardinality} types.
+ */
+public VertexProperty.Cardinality parseCardinality(final
GremlinParser.TraversalCardinalityArgumentContext ctx) {
+
[jira] [Updated] (TINKERPOP-2953) Static import for __.values() overriden by Column.values()
[
https://issues.apache.org/jira/browse/TINKERPOP-2953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2953:
Priority: Blocker (was: Critical)
> Static import for __.values() overriden by Column.values()
> --
>
> Key: TINKERPOP-2953
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2953
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy
>Affects Versions: 3.6.4
>Reporter: Stephen Mallette
>Assignee: Ken Hu
>Priority: Blocker
>
> this has always been a problem:
> {code}
> gremlin> :> values()
> ==>keys
> ==>values
> {code}
> but now after latest groovy upgrade in 3.6.3 we also get:
> {code}
> gremlin> :> values("a")
> No signature of method:
> org.apache.tinkerpop.gremlin.structure.Column$2.call() is applicable for
> argument types: (String) values: [a]
> Possible solutions: wait(), name(), any(), wait(long),
> tap(groovy.lang.Closure), each(groovy.lang.Closure)
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {code}
> Recommended workaround would be to prefer use of the explicit {{__}} or
> {{Column}} when there is potential for naming conflicts when using Groovy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties
[
https://issues.apache.org/jira/browse/TINKERPOP-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2957:
Priority: Blocker (was: Critical)
> mergeV with sideEffect not correctly updating properties
>
>
> Key: TINKERPOP-2957
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2957
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.4
>Reporter: Kelvin Lawrence
>Priority: Blocker
>
> A Gremlin user let me know about the following issue. If the query below is
> run twice, the name parameter on the 4567 vertex does not get updated. The
> name on the 1234 vertex does get updated. The query is written this way as
> not all databases support single cardinality as the default. The issue has
> been reproduced using both TinkerGraph and Amazon Neptune.
> {code:java}
> g.mergeV([(T.id): 'test-test-1234']).
> option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
> option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
> mergeV([(T.id): 'test-test-4567']).
> option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
> option(onMatch,
> sideEffect(property(single,"name","name2")).constant([:])){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2858) ConcurrentModificationException in ConnectiveStrategy
[
https://issues.apache.org/jira/browse/TINKERPOP-2858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2858:
Priority: Critical (was: Minor)
> ConcurrentModificationException in ConnectiveStrategy
> -
>
> Key: TINKERPOP-2858
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2858
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.6
>Reporter: Dylan Werner-Meier
>Priority: Critical
>
> I encountered a "ConcurrentModificationException" during a particularly
> difficult Gremlin query, on this specific line of code:
> {code:java}
> currentStep.getLabels().forEach(currentStep::removeLabel);
> {code}
> (
> [ConnectiveStrategy.java:98|https://github.com/apache/tinkerpop/blob/3.6-dev/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/strategy/decoration/ConnectiveStrategy.java#L98]
> )
>
> "currentStep.getLabels()" is a "LinkedHashSet", and it doesn't support
> concurrent iteration and modification.
>
> Proposed fix: add a "clearLabels()" method to "AbstractStep".
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2872) Inconsistency in comparing Elements in JavaScript tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2872: Priority: Critical (was: Minor) > Inconsistency in comparing Elements in JavaScript tests > --- > > Key: TINKERPOP-2872 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2872 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Priority: Critical > > In most GLV's we consider Elements the same when they have the same ID. > In JavaScript used [member wise > comparison|https://github.com/apache/tinkerpop/blob/master/gremlin-javascript/src/main/javascript/gremlin-javascript/test/cucumber/feature-steps.js#L176] > Make it work like the others GLV's, just compare ID. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2917) Please make specification of "valueMap()" step more index-friendly
[
https://issues.apache.org/jira/browse/TINKERPOP-2917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733205#comment-17733205
]
Stephen Mallette commented on TINKERPOP-2917:
-
[~martin.haeusler] did you get a chance to look at my comment above? does that
solve your problem?
> Please make specification of "valueMap()" step more index-friendly
> --
>
> Key: TINKERPOP-2917
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2917
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.6.2
>Reporter: Martin Häusler
>Priority: Major
>
> The {{valueMap(...)}} step states that it returns the property values found
> in the graph element. There's nothing inherently wrong with this definition,
> however it doesn't lend itself well to index-supported execution. For example:
> {code:java}
> traversal().V().has("type", "person").valueMap("firstName", "lastName")
> {code}
> This traversal may be executed on very large graphs entirely without loading
> a single element from disk, provided that {{{}type{}}}, {{firstName}} and
> {{lastName}} are indexed. That would be the ideal case, as it is roughly
> equivalent to a (commonly used) SQL query like this:
> {code:sql}
> SELECT firstName, lastName
> FROM person
> {code}
> The problems come in when the {{valueMap}} step should be answered from the
> secondary index:
> 1. Most secondary indices cannot distinguish between a list of "John", a set
> of "John", or the raw string value "John" (each entry of a multi-valued
> property is indexed separately).
> 2. Most secondary indices cannot distinguish between {{[ "John", "John" ]}}
> and {{["John"]}} (same values are written to the index only once per vertex).
> Issue 1 could be overcome if we had a schema on the graph, but for a
> schemaless graph there's no way to tell if the index result should be a list,
> a set or a raw string. Issue 2 isn't even solved if we had a schema (we would
> know that the property is a List, but we would have no way to tell how often
> a given value appears in the list).
> So, how can we answer {{valueMap()}} with index support? In ChronoGraph, I've
> introduced a setting {{{}USE_SECONDARY_INDEX_FOR_VALUE_MAP_STEP{}}}. If this
> setting is active, we deviate slightly from the gremlin {{valueMap()}}
> definition:
> - Each value will always be reported as a {{{}Set{}}}, even if the original
> vertex property was a single value or a List (i.e. only distinct values will
> be reported, in arbitrary order).
> - If the value was {{null}} or the property didn't exist on the vertex at
> all, an empty set is reported.
> This isn't harmful (as far as I can tell), but it is a difference to the
> standard behavior. In exchange, we get the possibility to scan our secondary
> indices to answer {{valueMap()}} steps, which is a great advantage in
> performance.
>
> I would very much like to see an adaptation of the standard (for example, the
> way I've described above) to make it more friendly towards index usage.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2927) Make all Steps extensible and overridable
[ https://issues.apache.org/jira/browse/TINKERPOP-2927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2927: Priority: Critical (was: Minor) > Make all Steps extensible and overridable > -- > > Key: TINKERPOP-2927 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2927 > Project: TinkerPop > Issue Type: Improvement > Components: driver >Affects Versions: 3.6.2 >Reporter: Oleksandr Porunov >Priority: Critical > > Related issue (fixed): https://issues.apache.org/jira/browse/TINKERPOP-2924 > > Working on optimization strategies sometimes require replacing steps with > extended version of those steps. At this moment not all steps can be extended > due to being `final` (like `ProjectStep`, `PropertyKeyStep`, > `PropertyValueStep`, `RangeLocalStep`, `SumLocalStep`, and many more). Thus, > it requires creating a similar step and duplicate some logic there instead of > simply extending a specific step. > > For those steps which are non-final there are sometimes private fields > without any getter methods (for example `private CallbackRegistry > callbackRegistry` in `DropStep` is `private`. Thus, the caller needs to use > Reflaction API to retrieve it's value). > > In JanusGraph we replace some steps with the extended version of those steps. > For example, we completely overwrite `flatMap` step of `PropertiesStep` which > is an anti-pattern, but in the case when it's hard to extend specific logic > parts such anti-pattern might be a a good solution I guess. > > I think it would make sense to let Graph developers to extend any step and > has access to it's fields / utility methods. > In such case we could do similar with `ProjectStep` and make it query data in > parallel (see issue: [https://github.com/JanusGraph/janusgraph/issues/3559] ). > > I'm also good not doing it in case anyone can suggest other patterns to > follow for those optimizations instead of overwriting logic. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2937) Throw an error when trying to use a closed connection
[
https://issues.apache.org/jira/browse/TINKERPOP-2937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2937:
Priority: Critical (was: Trivial)
> Throw an error when trying to use a closed connection
> -
>
> Key: TINKERPOP-2937
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2937
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.5.5
>Reporter: Valentyn Kahamlyk
>Priority: Critical
>
> When trying to use a closed connection in Python GLV, the application just
> hangs.
> {code:java}
> client = Client('ws://localhost:8182/gremlin', 'g')
> client.submit('2+2').all().result()
> client.close()
> client.submit('2+2').all().result(){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2938) Revisit merge step feature tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2938: Priority: Critical (was: Minor) > Revisit merge step feature tests > > > Key: TINKERPOP-2938 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2938 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.2 >Reporter: Yang Xia >Priority: Critical > > I've added a set of tests for > [https://github.com/apache/tinkerpop/pull/2036,] with the CTR here > [https://github.com/apache/tinkerpop/commit/2c9e5300d6901c72e565f89e50ab0e4844ccd56e]. > > Ideally I want the Feature test to check that the exception fails with the > intended error message, however, there seems to be a problem with the > exception falling through when you have an empty graph and invalid maps to > add just to g.V(['~label', vertex]). The intended errors appear to be null > when you check with the step, but then gets printed after in the terminal > output, which I wonder if it's not being caught in the toList() step, or if > there is some race going on. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2939) The Merge onMatch map validation is during execution instead of construction
[
https://issues.apache.org/jira/browse/TINKERPOP-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2939:
Priority: Critical (was: Minor)
> The Merge onMatch map validation is during execution instead of construction
>
>
> Key: TINKERPOP-2939
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2939
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.6.3
>Reporter: Yang Xia
>Priority: Critical
>
> A small thing I noticed related to TINKERPOP-2931.
> With an empty graph, the traversal
> {code:java}
> g.mergeV([:]).option(onMatch, ['~label', 'vertex']) {code}
> will create a new vertex, and since onMatch failed it doesn't apply anything
> inside regardless if it's a valid map or not, and will return
> {code:java}
> v[0]{code}
> This won't have any impact function-wise, since the onMatch map will be
> validated when the vertex is found, but just wondering if we should validate
> this on construction instead of execution?
> A more visual example on 3.6.3-SNAPSHOT console.
> {code:java}
> gremlin> g.mergeV([:]).option(Merge.onMatch, ['~label':'vertex'])
> ==>v[0]
> gremlin> g.mergeV([:]).option(Merge.onMatch, ['~label':'vertex'])
> Property key can not be a hidden key: ~label
> Type ':help' or ':h' for help.
> Display stack trace? [yN]n
> gremlin> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2940) Strategy Dependent Behavior of Ternary Boolean Logic
[
https://issues.apache.org/jira/browse/TINKERPOP-2940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2940:
Priority: Critical (was: Major)
> Strategy Dependent Behavior of Ternary Boolean Logic
>
>
> Key: TINKERPOP-2940
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2940
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.6.2
>Reporter: Cole Greer
>Priority: Critical
>
> The current implementation of [ternary boolean
> logic|https://tinkerpop.apache.org/docs/3.6.2/dev/provider/#_ternary_boolean_logics]
> in TinkerPop leads to inconsistent and unexpected behavior depending on
> strategy application. This stems from the binary reduction logic implemented
> [here|https://github.com/Bit-Quill/tinkerpop/blob/d653b2401271ff9eb8e2249f878344c27ac81418/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/FilterStep.java#L44].
> `TraversalFilterStep` and `WhereStep` are currently special cases which will
> trigger early reduction of boolean error states to false. The issue is that
> some strategies such as `InlineFilterStrategy` will sometimes remove such
> steps to produce optimized traversals which are almost equivalent, but don't
> have this early reduction behavior.
> Here is a simple example of this in TinkerGraph 3.6.2:
> {code:bash}
> gremlin>
> g.withoutStrategies(InlineFilterStrategy).inject(1).not(where(is(lt(NaN
> ==>1
> gremlin>
> g.withoutStrategies(InlineFilterStrategy).inject(1).not(where(is(lt(NaN.explain()
> ==>Traversal Explanation
> ==
> Original Traversal[InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> ConnectiveStrategy [D] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> CountStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> IdentityRemovalStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> EarlyLimitStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> MatchPredicateStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> IncidentToAdjacentStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> AdjacentToIncidentStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> FilterRankingStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> ByModulatorOptimizationStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> RepeatUnrollStrategy[O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> PathRetractionStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> LazyBarrierStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> TinkerGraphCountStrategy[P] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> TinkerGraphStepStrategy [P] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> ProfileStrategy [F] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> StandardVerificationStrategy[V] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> Final Traversal [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> gremlin> g.inject(1).not(where(is(lt(NaN
> gremlin> g.inject(1).not(where(is(lt(NaN.explain()
> ==>Traversal Explanation
> ==
> Original Traversal[InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> ConnectiveStrategy [D] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> CountStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> IdentityRemovalStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> EarlyLimitStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> MatchPredicateStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> FilterRankingStrategy [O] [InjectStep([1]),
> NotStep([TraversalFilterStep([IsStep(lt(NaN))])])]
> InlineFilterStrategy[O]
[jira] [Updated] (TINKERPOP-2948) PRISMA security vulnerabilty for jackson-databind 2.14.0
[
https://issues.apache.org/jira/browse/TINKERPOP-2948?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2948:
Priority: Critical (was: Major)
> PRISMA security vulnerabilty for jackson-databind 2.14.0
>
>
> Key: TINKERPOP-2948
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2948
> Project: TinkerPop
> Issue Type: Bug
> Components: server
>Affects Versions: 3.6.3, 3.5.6
>Reporter: Aaron Coady
>Priority: Critical
>
>
> h1. PRISMA-2023-0067 logged against jackson-databind 2.14.0
> [https://github.com/FasterXML/jackson-core/pull/827]
>
> com.fasterxml.jackson.core_jackson-core package versions before 2.15.0 are
> vulnerable to Denial of Service (DoS). The package does not properly restrict
> the size or amount of resources that are requested or influenced by an actor,
> which can be used to consume more resources than intended and leads to
> Uncontrolled Resource Consumption ('Resource Exhaustion')
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2949) More strict handling of predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2949: Priority: Critical (was: Major) > More strict handling of predicates > -- > > Key: TINKERPOP-2949 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2949 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Priority: Critical > > P, TextP, ConnectiveP now accept arbitrary `biPredicate` as argument, which > can lead to serialization problems. Introduce new interface over > `biPredicate` to make predicate naming more strict -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties
[
https://issues.apache.org/jira/browse/TINKERPOP-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2957:
Priority: Critical (was: Major)
> mergeV with sideEffect not correctly updating properties
>
>
> Key: TINKERPOP-2957
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2957
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.4
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> A Gremlin user let me know about the following issue. If the query below is
> run twice, the name parameter on the 4567 vertex does not get updated. The
> name on the 1234 vertex does get updated. The query is written this way as
> not all databases support single cardinality as the default. The issue has
> been reproduced using both TinkerGraph and Amazon Neptune.
> {code:java}
> g.mergeV([(T.id): 'test-test-1234']).
> option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
> option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
> mergeV([(T.id): 'test-test-4567']).
> option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
> option(onMatch,
> sideEffect(property(single,"name","name2")).constant([:])){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2832) Nature of sessions and driver reconnect allow bytecode transactions to appear to remain open
[ https://issues.apache.org/jira/browse/TINKERPOP-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2832: Priority: Major (was: Critical) > Nature of sessions and driver reconnect allow bytecode transactions to appear > to remain open > > > Key: TINKERPOP-2832 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2832 > Project: TinkerPop > Issue Type: Bug > Components: driver, server >Affects Versions: 3.5.4 >Reporter: Stephen Mallette >Priority: Major > > The driver is design to reconnect if it loses its connection to the server. > For sessions a close can happen if there is a timeout on the session itself. > On the server the session is invalidated, but on the client side, it tries to > reconnect using the same session id. Unfortunately this reconnect creates a > scenario for bytecode transactions where it can appear as though you're > working the same transaction when you are not. > Test to demonstrate shown > [here|https://github.com/apache/tinkerpop/commit/4528ec33ab56e3c0526ad8b38494674c64754e54] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2961) Missing exceptions for unsolvable match pattern, which may lead to logic inconsistency
[
https://issues.apache.org/jira/browse/TINKERPOP-2961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2961:
Component/s: process
> Missing exceptions for unsolvable match pattern, which may lead to logic
> inconsistency
> --
>
> Key: TINKERPOP-2961
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2961
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.0
>Reporter: Miracy Cavendish
>Priority: Major
> Attachments: create-8.log
>
>
> Hi all! From
> [Discord|https://discord.com/channels/838910279550238720/1064868348925583442/threads/1117146194666332250].
> We noticed that in some cases unsolvable matching will not lead to the
> exception "unsolvable pattern" in Gremlin.
> For a simple example, in the empty graph, the following query will not lead
> to an exception, while it will result in an exception in the GraphModern:
> {code:java}
> g.V().match(__.as("A").out().as("B"), __.as("C").out().as("B"),
> __.as("D").out().as("A"))
> {code}
> In more complex cases, this missing may lead to a worse result.
> For example, in the graph created by attachment _create-8.log_
> {code:java}
> g.V().match(
> __.as("n2").out().as("n1"),
> __.as("n2").in().in().in().both().in().as("n1"),
> __.as("n2").both().in().in().as("n3"),
> __.as("n3").in().both().as("n2"),
> __.as("n2").in().in().in().in().both().as("n4"),
> __.as("n2").out().both().in().as("n4"),
> __.as("n3").both().as("n4"),
> __.as("n1").in().both().both().both().as("n5")
> ).dedup().count()
> =>306691
> g.V().match(
> __.as("n2").out().as("n1"),
> __.as("n2").in().in().in().both().in().as("n1"),
> __.as("n2").both().in().in().as("n3"),
> __.as("n3").in().both().as("n2"),
> __.as("n4").both().out().out().out().out().as("n2"),
> __.as("n2").out().both().in().as("n4"),
> __.as("n3").both().as("n4"),
> __.as("n1").in().both().both().both().as("n5")
> ).dedup().count()
> =>306075
> {code}
> The two queries are equivalent, the only difference is the expression of the
> traversal "__.as("n4").both().out().out().out().out().as("n2")".
> I am not sure which of their results in the correct result, but the logic
> inconsistency indicates that the missing exception may cause worse results
> than we thought before.
> After the discussion with [~spmallette], we believe that it would be better
> if detect the unsolvable pattern before the execution.
> {*}In addition{*}, *it would be highly appreciated if someone can reproduce
> and confirm the logic inconsistency in the complex cases. I think it may
> imply other potential issues of the traversal strategies.* And if such logic
> inconsistency still exists using both solvable equivalent patterns, we will
> reduce & report is ASAP.
>
> Best regards,
> Joye Mang
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2920) SubgraphStrategy failure when property key not present on vertex in by()
[
https://issues.apache.org/jira/browse/TINKERPOP-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-2920:
Description:
The following triggers the failure assuming "example" isn't present on a vertex:
{code}
g.withStrategies(new SubgraphStrategy(vertexProperties: constant(true))).
V().project("example").by("example")
{code}
Note that {{values('example")}} will work on 3.6.2, but not 3.5.5 which
probably has something to do with differences in {{by()}} handling and
{{ProductiveByStrategy}}.
{code}
gremlin> g.withStrategies(new SubgraphStrategy(vertexProperties:
constant(true))).
..1> withoutStrategies(ProductiveByStrategy).
..2> V().project("example").by(values("example"))
The provided traverser does not map to a value:
v[1][TinkerVertex]->[PropertiesStep([example],property),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]),
PropertyValueStep][DefaultGraphTraversal] parent[[TinkerGraphStep(vertex,[]),
ProjectStep([example],[[PropertiesStep([example],property),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]), PropertyValueStep]])]]
Type ':help' or ':h' for help.
Display stack trace? [yN]
..1> V().project("example").by("example")
The provided traverser does not map to a value:
v[1][TinkerVertex]->[PropertiesStep([example],property),
TraversalFilterStep([ConstantStep(true)]),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]),
PropertyValueStep][DefaultTraversal]
parent[[CoalesceStep([value([PropertiesStep([example],property),
TraversalFilterStep([ConstantStep(true)]),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]), PropertyValueStep]), (null)])]]
Type ':help' or ':h' for help.
Display stack trace? [yN]
{code}
was:
The following triggers the failure assuming "example" isn't present on a vertex:
{code}
g.withStrategies(new SubgraphStrategy(vertexProperties: constant(true))).
V().project("example").by("example")
{code}
Note that {{values('example")}} will work on 3.6.2, but not 3.5.5 which
probably has something to do with differences in {{by()}} handling and
{{ProductiveByStrategy}}.
{code}
gremlin> g.withStrategies(new SubgraphStrategy(vertexProperties:
constant(true))).
..1> withoutStrategies(ProductiveByStrategy).
..2> V().project("example").by(values("example"))
The provided traverser does not map to a value:
v[1][TinkerVertex]->[PropertiesStep([example],property),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]),
PropertyValueStep][DefaultGraphTraversal] parent[[TinkerGraphStep(vertex,[]),
ProjectStep([example],[[PropertiesStep([example],property),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]), PropertyValueStep]])]]
Type ':help' or ':h' for help.
Display stack trace? [yN]
{code}
> SubgraphStrategy failure when property key not present on vertex in by()
>
>
> Key: TINKERPOP-2920
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2920
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Priority: Minor
>
> The following triggers the failure assuming "example" isn't present on a
> vertex:
> {code}
> g.withStrategies(new SubgraphStrategy(vertexProperties: constant(true))).
> V().project("example").by("example")
> {code}
> Note that {{values('example")}} will work on 3.6.2, but not 3.5.5 which
> probably has something to do with differences in {{by()}} handling and
> {{ProductiveByStrategy}}.
> {code}
> gremlin> g.withStrategies(new SubgraphStrategy(vertexProperties:
> constant(true))).
> ..1> withoutStrategies(ProductiveByStrategy).
> ..2> V().project("example").by(values("example"))
> The provided traverser does not map to a value:
> v[1][TinkerVertex]->[PropertiesStep([example],property),
> OrStep([[ClassFilterStep(VertexProperty)],
> [TraversalFilterStep([ConstantStep(true)])]]),
> PropertyValueStep][DefaultGraphTraversal] parent[[TinkerGraphStep(vertex,[]),
> ProjectStep([example],[[PropertiesStep([example],property),
> OrStep([[ClassFilterStep(VertexProperty)],
> [TraversalFilterStep([ConstantStep(true)])]]), PropertyValueStep]])]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> ..1> V().project("example").by("example")
> The provided traverser does not map to a value:
> v[1][TinkerVertex]->[PropertiesStep([example],property),
> TraversalFilterStep([ConstantStep(true)]),
> OrStep([[ClassFilterStep(VertexProperty)],
> [TraversalFilterStep([ConstantStep(true)])]]),
> PropertyValueStep][DefaultTraversal]
>
[jira] [Updated] (TINKERPOP-2920) SubgraphStrategy failure when property key not present on vertex in by()
[
https://issues.apache.org/jira/browse/TINKERPOP-2920?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-2920:
Description:
The following triggers the failure assuming "example" isn't present on a vertex:
{code}
g.withStrategies(new SubgraphStrategy(vertexProperties: constant(true))).
V().project("example").by("example")
{code}
Note that {{values('example")}} will work on 3.6.2, but not 3.5.5 which
probably has something to do with differences in {{by()}} handling and
{{ProductiveByStrategy}}.
{code}
gremlin> g.withStrategies(new SubgraphStrategy(vertexProperties:
constant(true))).
..1> withoutStrategies(ProductiveByStrategy).
..2> V().project("example").by(values("example"))
The provided traverser does not map to a value:
v[1][TinkerVertex]->[PropertiesStep([example],property),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]),
PropertyValueStep][DefaultGraphTraversal] parent[[TinkerGraphStep(vertex,[]),
ProjectStep([example],[[PropertiesStep([example],property),
OrStep([[ClassFilterStep(VertexProperty)],
[TraversalFilterStep([ConstantStep(true)])]]), PropertyValueStep]])]]
Type ':help' or ':h' for help.
Display stack trace? [yN]
{code}
was:
The following triggers the failure assuming "example" isn't present on a vertex:
{code}
g.withStrategies(new SubgraphStrategy(vertexProperties: constant(true))).
V().project("example").by("example")
{code}
Note that {[values('example")}} will work on 3.6.2, but not 3.5.5 which
probably has something to do with differences in {{by()}} handling and
{{ProductiveByStrategy}}.
> SubgraphStrategy failure when property key not present on vertex in by()
>
>
> Key: TINKERPOP-2920
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2920
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Priority: Minor
>
> The following triggers the failure assuming "example" isn't present on a
> vertex:
> {code}
> g.withStrategies(new SubgraphStrategy(vertexProperties: constant(true))).
> V().project("example").by("example")
> {code}
> Note that {{values('example")}} will work on 3.6.2, but not 3.5.5 which
> probably has something to do with differences in {{by()}} handling and
> {{ProductiveByStrategy}}.
> {code}
> gremlin> g.withStrategies(new SubgraphStrategy(vertexProperties:
> constant(true))).
> ..1> withoutStrategies(ProductiveByStrategy).
> ..2> V().project("example").by(values("example"))
> The provided traverser does not map to a value:
> v[1][TinkerVertex]->[PropertiesStep([example],property),
> OrStep([[ClassFilterStep(VertexProperty)],
> [TraversalFilterStep([ConstantStep(true)])]]),
> PropertyValueStep][DefaultGraphTraversal] parent[[TinkerGraphStep(vertex,[]),
> ProjectStep([example],[[PropertiesStep([example],property),
> OrStep([[ClassFilterStep(VertexProperty)],
> [TraversalFilterStep([ConstantStep(true)])]]), PropertyValueStep]])]]
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2930) shouldContinueToEvalScriptsEvenWithTimedInterrupt is failing intermittently
[
https://issues.apache.org/jira/browse/TINKERPOP-2930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette closed TINKERPOP-2930.
---
Resolution: Cannot Reproduce
haven't seen this in a while and haven't been able to reproduce
> shouldContinueToEvalScriptsEvenWithTimedInterrupt is failing intermittently
> ---
>
> Key: TINKERPOP-2930
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2930
> Project: TinkerPop
> Issue Type: Bug
> Components: groovy
>Affects Versions: 3.7.0
>Reporter: Stephen Mallette
>Priority: Major
>
> This failure seems to only be happening on 3.7.x. Perhaps related to the
> groovy upgrade?
> {code}
> javax.script.ScriptException: javax.script.ScriptException:
> org.apache.tinkerpop.gremlin.groovy.jsr223.TimedInterruptTimeoutException:
> Execution timed out after 1000 milliseconds. Start time: Fri Apr 21 09:32:39
> EDT 2023
> at
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:383)
> at
> java.scripting/javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264)
> at
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngineTimedInterruptTest.shouldContinueToEvalScriptsEvenWithTimedInterrupt(GremlinGroovyScriptEngineTimedInterruptTest.java:74)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:56)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at
> org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
> at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
> at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
> at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
> at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at
> com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:69)
> at
> com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
> at
> com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:235)
> at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:54)
> Caused by: javax.script.ScriptException:
> org.apache.tinkerpop.gremlin.groovy.jsr223.TimedInterruptTimeoutException:
> Execution timed out after 1000 milliseconds. Start time: Fri Apr 21 09:32:39
> EDT 2023
> at
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:702)
> at
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:381)
> ... 27 more
> Caused by:
> org.apache.tinkerpop.gremlin.groovy.jsr223.TimedInterruptTimeoutException:
> Execution timed out after 1000 milliseconds. Start time: Fri Apr 21 09:32:39
> EDT 2023
> at
> org.codehaus.groovy.vmplugin.v8.IndyInterface.fromCache(IndyInterface.java:321)
> at Script7.run(Script7.groovy:2)
> at
> org.apache.tinkerpop.gremlin.groovy.jsr223.GremlinGroovyScriptEngine.eval(GremlinGroovyScriptEngine.java:679)
> ... 28 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2955) Support SSL in WebSocketClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette closed TINKERPOP-2955. --- Fix Version/s: 3.7.0 3.5.7 3.6.5 Assignee: Stephen Mallette Resolution: Fixed > Support SSL in WebSocketClient > -- > > Key: TINKERPOP-2955 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2955 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.6.4 >Reporter: Redriver >Assignee: Stephen Mallette >Priority: Major > Fix For: 3.7.0, 3.5.7, 3.6.5 > > > The WebSocketClient in gremlin-driver does not support SSL. As a result, when > the gremlin-server enables SSL, the WebSocketClient failed to connect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2955) Support SSL in WebSocketClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephen Mallette updated TINKERPOP-2955: Component/s: test-suite > Support SSL in WebSocketClient > -- > > Key: TINKERPOP-2955 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2955 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.6.4 >Reporter: Redriver >Priority: Major > > The WebSocketClient in gremlin-driver does not support SSL. As a result, when > the gremlin-server enables SSL, the WebSocketClient failed to connect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2955) Support SSL in WebSocketClient
[ https://issues.apache.org/jira/browse/TINKERPOP-2955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17733038#comment-17733038 ] ASF GitHub Bot commented on TINKERPOP-2955: --- spmallette merged PR #2079: URL: https://github.com/apache/tinkerpop/pull/2079 > Support SSL in WebSocketClient > -- > > Key: TINKERPOP-2955 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2955 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.6.4 >Reporter: Redriver >Priority: Major > > The WebSocketClient in gremlin-driver does not support SSL. As a result, when > the gremlin-server enables SSL, the WebSocketClient failed to connect. -- This message was sent by Atlassian Jira (v8.20.10#820010)
