[jira] [Created] (TINKERPOP-3095) Provide a path for selecting script engine for traversals in TP4
Valentyn Kahamlyk created TINKERPOP-3095:
Summary: Provide a path for selecting script engine for traversals
in TP4
Key: TINKERPOP-3095
URL: https://issues.apache.org/jira/browse/TINKERPOP-3095
Project: TinkerPop
Issue Type: Improvement
Components: driver
Affects Versions: 4.0.0
Reporter: Valentyn Kahamlyk
For string queries there is now a simple way to select script engine which the
query will be executed
{code:java}
final RequestOptions ro =
RequestOptions.build().language("gremlin-lang").create();
final List result = client.submit("g.inject(1)", ro).toList();{code}
We need to do the same thing for traversal based requests, Something like
{code:java}
final GraphTraversalSource g =
traversal().with(DriverRemoteConnection.using(cluster)).with("language",
"gremlin-lang");
final List result = g.inject(1).toList());{code}
*or*
{code:java}
final GraphTraversalSource g =
traversal().with(DriverRemoteConnection.using(cluster, "g", "gremlin-lang));
final List result = g.inject(1).toList());{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3091) Add feature tests for `call()` step
Valentyn Kahamlyk created TINKERPOP-3091: Summary: Add feature tests for `call()` step Key: TINKERPOP-3091 URL: https://issues.apache.org/jira/browse/TINKERPOP-3091 Project: TinkerPop Issue Type: Improvement Components: test-suite Affects Versions: 4.0.0 Reporter: Valentyn Kahamlyk We have some feature tests coverage for `call()` step, but for some reason its execution is now on the ignored list. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3077) Javascript translator incorrectly handle quotes, null and undefined values
Valentyn Kahamlyk created TINKERPOP-3077:
Summary: Javascript translator incorrectly handle quotes, null and
undefined values
Key: TINKERPOP-3077
URL: https://issues.apache.org/jira/browse/TINKERPOP-3077
Project: TinkerPop
Issue Type: Improvement
Components: javascript
Affects Versions: 3.7.2, 3.6.7
Reporter: Valentyn Kahamlyk
If there are `null` or `undefined` values in queries, the translator converts
them incorrectly. `null` converted as string "null" and `undefined` is simply
skipped.
Quotes are not properly escaped
Simple reproducer.
{code:javascript}
const script1 = new Translator('g')
.translate(g.addV('test').property('empty', null).getBytecode());
console.log(script1);
const script2 = new Translator('g')
.translate(g.addV('test').property('empty', undefined).getBytecode());
console.log(script2);
const script3 = new Translator('g')
.translate(g.addV('test').property('quotes', "some \"quotes' in the
middle.").getBytecode());
console.log(script3);{code}
output:
{code:java}
g.addV('test').property('empty', 'null')
g.addV('test').property('empty', )
g.addV('test').property('quotes', 'some "quotes' in the middle.')
{code}
which results in a server error when submitting translated query.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3076) Incorrect handling of large requests in Go GLV
Valentyn Kahamlyk created TINKERPOP-3076:
Summary: Incorrect handling of large requests in Go GLV
Key: TINKERPOP-3076
URL: https://issues.apache.org/jira/browse/TINKERPOP-3076
Project: TinkerPop
Issue Type: Improvement
Components: go
Affects Versions: 3.7.2, 3.6.7
Reporter: Valentyn Kahamlyk
When trying to send a request longer than about a megabyte, go GLV does not
work correctly, possibly truncates data.
Simple reproducer
{code:go}
func main() {
driverRemoteConnection, err :=
gremlingo.NewDriverRemoteConnection("ws://localhost:8182/gremlin")
if err != nil {
fmt.Println(err)
return
}
defer driverRemoteConnection.Close()
g := gremlingo.Traversal_().WithRemote(driverRemoteConnection)
const count = 1100
var ids [count]string
const idLength = 1000
result := make([]byte, idLength)
for i := 0; i < idLength; i++ {
result[i] = 65
}
id := string(result)
for i := 0; i < count; i++ {
ids[i] = id
}
r, err := g.V(ids).Count().ToList()
if err != nil {
fmt.Println("err: ", err)
return
}
fmt.Println("found: ", r[0].GetString())
}{code}
with `count = 1000` it works as expected.
Python GLV works as expected with same request.
Error logged in Gremlin Server
{code:java}
io.netty.handler.codec.DecoderException: java.lang.IndexOutOfBoundsException:
readerIndex(1048338) + length(1000) exceeds writerIndex(1048543):
PooledUnsafeDirectByteBuf(ridx: 1048338, widx: 1048543, cap: 1048576){code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2027. Resolution: Fixed > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > Fix For: 4.0.0 > > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2027: - Fix Version/s: 4.0.0 > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > Fix For: 4.0.0 > > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2027) Add a Typescript definitions file to the project
[ https://issues.apache.org/jira/browse/TINKERPOP-2027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk reopened TINKERPOP-2027: -- > Add a Typescript definitions file to the project > > > Key: TINKERPOP-2027 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2027 > Project: TinkerPop > Issue Type: Improvement > Components: javascript >Affects Versions: 3.3.3, 3.2.9 >Reporter: Matthew Allen >Priority: Major > > For those using Typescript it would be great to provide a type definition > file for the glv. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3054) RequestId serialization broken in Python GLV
Valentyn Kahamlyk created TINKERPOP-3054:
Summary: RequestId serialization broken in Python GLV
Key: TINKERPOP-3054
URL: https://issues.apache.org/jira/browse/TINKERPOP-3054
Project: TinkerPop
Issue Type: Improvement
Components: python
Affects Versions: 3.7.1, 3.6.6
Reporter: Valentyn Kahamlyk
`g.with_('requestId', uuid.uuid1()).V().count().toList()`
failed with error `AttributeError: 'UUID' object has no attribute 'replace'`
in line
`uuid.UUID(request_id) # Checks for proper UUID or else server will return an
error.`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3044) Add the ability to explicitly specify the type for numeric data in JavaScript GLV
Valentyn Kahamlyk created TINKERPOP-3044: Summary: Add the ability to explicitly specify the type for numeric data in JavaScript GLV Key: TINKERPOP-3044 URL: https://issues.apache.org/jira/browse/TINKERPOP-3044 Project: TinkerPop Issue Type: Improvement Components: javascript Reporter: Valentyn Kahamlyk Now integer value can be serialized only as Int or Long, and users can't select type explicitly. [implementation|https://github.com/apache/tinkerpop/blob/963bece33ce0f662ea8e6106b1128e27b587aaed/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/structure/io/binary/internals/NumberSerializationStrategy.js#L57] Add support for Byte and Short, allow so select type for any number, for example send 1 as Byte or Short or Int or Long or Double, etc. Find a way to handle values outside [MIN_SAFE_INTEGER,MAX_SAFE_INTEGER]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3043) Add BigDecimal support to JavaScript GLV
Valentyn Kahamlyk created TINKERPOP-3043: Summary: Add BigDecimal support to JavaScript GLV Key: TINKERPOP-3043 URL: https://issues.apache.org/jira/browse/TINKERPOP-3043 Project: TinkerPop Issue Type: Improvement Components: javascript Affects Versions: 3.7.1, 3.6.6 Reporter: Valentyn Kahamlyk Add the ability to work BigDecimal numbers in JavaScript GLV. Additional complexity is the transfer of large values as Number in GraphSON described in https://issues.apache.org/jira/browse/TINKERPOP-2156 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3027) Pick.any should be any_()
[
https://issues.apache.org/jira/browse/TINKERPOP-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-3027.
Fix Version/s: 4.0.0
3.6.7
3.7.2
Resolution: Fixed
> Pick.any should be any_()
> -
>
> Key: TINKERPOP-3027
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3027
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.6
>Reporter: Stephen Mallette
>Priority: Critical
> Fix For: 4.0.0, 3.6.7, 3.7.2
>
>
> Documentation shows {{any_()}} in the "Differences" section of the python
> docs but it doesn't appear to be implemented.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3037) Improve error handling for GraphBinary
Valentyn Kahamlyk created TINKERPOP-3037:
Summary: Improve error handling for GraphBinary
Key: TINKERPOP-3037
URL: https://issues.apache.org/jira/browse/TINKERPOP-3037
Project: TinkerPop
Issue Type: Improvement
Components: server
Affects Versions: 3.7.1, 3.6.6
Reporter: Valentyn Kahamlyk
Now when there is an error with deserializing `RequestMessage` from GLV's, it
will hands forever.
The reason is that for any response (including error message) server need a
request ID which in this case is lost.
Server can return correct error message when RequestMessage is in correct
format, but traversal is invalid, for example:
- newly added steps can't be deserialized, like 3.7.1 client with 3.7.0 server
- some other issues like I got with incorrect type, example for .net GLV:
`g.AddV().Property("test", GremlinType.FromFqcn("test")).Next()`
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3012) Wrong hashCode implementation for DetachedVertexPropert
[ https://issues.apache.org/jira/browse/TINKERPOP-3012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798396#comment-17798396 ] Valentyn Kahamlyk commented on TINKERPOP-3012: -- Hi [~tglman], Equality for vertex properties is defined in the same way as for Elements, i.e. by Id, not by value. DetachedVertexProperty inherits `hashCode` from DetachedElement. DetachedVertexProperty overrides `equals` implementation, but code is the same. The expected behavior of `VertexProperty` can be found, for example here https://github.com/apache/tinkerpop/blob/7f350528343606c51046016d9d6e748d0b2bae7c/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/ElementHelper.java#L430 > Wrong hashCode implementation for DetachedVertexPropert > --- > > Key: TINKERPOP-3012 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3012 > Project: TinkerPop > Issue Type: Bug > Components: process >Affects Versions: 3.7.0 >Reporter: Emanuele Tagliaferri >Priority: Major > Attachments: detached_vertex_property_hashcode.patch > > > Hi, > I was trying to update OrientDB to TinkerPop 3.7.0, and I got some test > failing, with some debugging I noticed that the `DetachedVertexProperty` > implement equals for the property, but inherit the hashCode from > `DetachedElement` that it does not behave as a property but as an element. It > may be there also other `VertextProperty` that do not implement correctly the > hashCode. > Adding a simple example patch in attachment. > here is the branch I'm working on for the update > https://github.com/orientechnologies/orientdb-gremlin/tree/WIP_update_deps I > do have additional tests failing to check -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17798353#comment-17798353
]
Valentyn Kahamlyk commented on TINKERPOP-3015:
--
now it's equivalent
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/dsl/graph/GraphTraversal.java#L2382
> Use wildcard instead of Object for hasId predicates
> ---
>
> Key: TINKERPOP-3015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3015
> Project: TinkerPop
> Issue Type: Improvement
>Affects Versions: 3.5.7, 3.6.5
>Reporter: Christopher Smith
>Priority: Minor
>
> From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a
> {{P}}. Common predicates, such as {{within}}, propagate the generic
> type from their own arguments, so that this produces a compile-time error:
> {code}
> Collection ids = ...
> g.V().hasId(P.within(ids))
> {code}
> I believe that without loss of safety, the signature in both locations could
> be changed to {{P}}, making the typical case of "here's a collection of
> IDs of known type" work smoothly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2913) Ensure that if tx.commit() is called remotely it does not hang for graphs without transactions
[
https://issues.apache.org/jira/browse/TINKERPOP-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2913:
Assignee: Valentyn Kahamlyk
> Ensure that if tx.commit() is called remotely it does not hang for graphs
> without transactions
> --
>
> Key: TINKERPOP-2913
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2913
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet, go, javascript, python
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Assignee: Valentyn Kahamlyk
>Priority: Critical
>
> Javascript has been reported to hang if you do a {{tx.commit()}} and the
> remote graph does not support transactions (i.e. TinkerGraph). It should
> return an exception similar to how Java does:
> {code}
> gremlin> tx.commit()
> Transaction commit for Optional.empty failed
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
>
> Caused by: java.util.concurrent.CompletionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Graph does
> not support transactions
> at
> java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375)
> at
> java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1947)
> at org.apache.tinkerpop.gremlin.driver.ResultSet.one(ResultSet.java:123)
> at
> org.apache.tinkerpop.gremlin.driver.ResultSet$1.hasNext(ResultSet.java:175)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal$TraverserIterator.hasNext(DriverRemoteTraversal.java:110)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal.hasNext(DriverRemoteTraversal.java:70)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTransaction.closeRemoteTransaction(DriverRemoteTransaction.java:95)
> ... 70 more
> Caused by: org.apache.tinkerpop.gremlin.driver.exception.ResponseException:
> Graph does not support transactions
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:245)
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:200)
> at
> {code}
> Check all non-java drivers and provide tests to enforce the appropriate
> behavior. It would be worth examining behavior of all {{tx}} methods like
> {{rollback()}} and {{close()}} as well. can this be somehow part of the
> gherkin test suite rather than one-off tests?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2913) Ensure that if tx.commit() is called remotely it does not hang for graphs without transactions
[
https://issues.apache.org/jira/browse/TINKERPOP-2913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2913.
Fix Version/s: 3.6.7
3.7.2
Resolution: Fixed
> Ensure that if tx.commit() is called remotely it does not hang for graphs
> without transactions
> --
>
> Key: TINKERPOP-2913
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2913
> Project: TinkerPop
> Issue Type: Bug
> Components: dotnet, go, javascript, python
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.6.7, 3.7.2
>
>
> Javascript has been reported to hang if you do a {{tx.commit()}} and the
> remote graph does not support transactions (i.e. TinkerGraph). It should
> return an exception similar to how Java does:
> {code}
> gremlin> tx.commit()
> Transaction commit for Optional.empty failed
> Type ':help' or ':h' for help.
> Display stack trace? [yN]y
>
> Caused by: java.util.concurrent.CompletionException:
> org.apache.tinkerpop.gremlin.driver.exception.ResponseException: Graph does
> not support transactions
> at
> java.util.concurrent.CompletableFuture.reportJoin(CompletableFuture.java:375)
> at
> java.util.concurrent.CompletableFuture.join(CompletableFuture.java:1947)
> at org.apache.tinkerpop.gremlin.driver.ResultSet.one(ResultSet.java:123)
> at
> org.apache.tinkerpop.gremlin.driver.ResultSet$1.hasNext(ResultSet.java:175)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal$TraverserIterator.hasNext(DriverRemoteTraversal.java:110)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTraversal.hasNext(DriverRemoteTraversal.java:70)
> at
> org.apache.tinkerpop.gremlin.driver.remote.DriverRemoteTransaction.closeRemoteTransaction(DriverRemoteTransaction.java:95)
> ... 70 more
> Caused by: org.apache.tinkerpop.gremlin.driver.exception.ResponseException:
> Graph does not support transactions
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:245)
> at
> org.apache.tinkerpop.gremlin.driver.Handler$GremlinResponseHandler.channelRead0(Handler.java:200)
> at
> {code}
> Check all non-java drivers and provide tests to enforce the appropriate
> behavior. It would be worth examining behavior of all {{tx}} methods like
> {{rollback()}} and {{close()}} as well. can this be somehow part of the
> gherkin test suite rather than one-off tests?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2990) Javascript GLV: Add getters and setters for Client and Connection classes
[
https://issues.apache.org/jira/browse/TINKERPOP-2990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17787383#comment-17787383
]
Valentyn Kahamlyk commented on TINKERPOP-2990:
--
Adding setter is quite a risky move. Currently Client can only work with one
Connection, and Connection not designed to work with several Clients.
Connection constructor use same options as Client constructor, so technically,
a Client-created Connection will be exactly the same as Connection created in
other place.
Do you have an example of when setter is needed?
> Javascript GLV: Add getters and setters for Client and Connection classes
> -
>
> Key: TINKERPOP-2990
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2990
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.7.0
>Reporter: Taylor Riggan
>Priority: Critical
>
> Java provides the ability to override a class constructor, which has allowed
> a Client or Connection class in Java to be instantiated using varying
> different parameters. Javascript classes only allow a single constructor.
> This limits a developer's ability to access or modify class properties for a
> Client or Connection object.
> Example:
> A DriverRemoteConnection object in gremlin-javascript can only be
> instantiated via:
> {code:java}
> let drc = new DriverRemoteConnection(some_url);{code}
> A developer would not be able to create a Client object first and create a
> new DriverRemoteConnection object based on the Client as they would be able
> to do using the Java GLV.
>
> Similarly, if a user needed to gain access to an underlying Client or
> Connection object from within a DriverRemoteConnection, they would be
> accessing these properties using the _client or _connection variable names.
> The underscore prefix typically denotes that these should be viewed as
> private class properties. As such, we should be treating these as private
> until a time comes as to when we can adopt actual private class properties
> and functions (a fairly new concept added to JS in ES2019).
> To address these issues, I suggest we add setter and getter functions to the
> respective classes that would allow a user to more properly interact with
> class properties that cannot be defined via overridden constructor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2877) The incorrect result caused by long integer overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2877.
Resolution: Fixed
> The incorrect result caused by long integer overflows
> -
>
> Key: TINKERPOP-2877
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2877
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
> Fix For: 4.0.0
>
>
> {code:java}
> Gremlin1:
> g.V().both().both().both().both().both().both().values('prop9').sum()
> Result1: -5308416236269507008
> Gremlin2:
> g.V().both().both().both().both().both().both().has('prop2').values('prop9').sum()
> Result2: 756493433251093
> Gremlin3:
> g.V().both().both().both().both().both().both().hasNot('prop2').values('prop9').sum()
> Result3: -8222751935482731416{code}
> We execute the above gremlin queries: Result1 should equal the sum of Result2
> and Result3, whereas -5308416236269507008 ≠756493433251093 +
> -8222751935482731416.
> The possible reason is that long integer overflows happen in the process.
> Could you return an exception to notify the user when the overflow occurs, or
> use BigDecimal during the procedure?
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
> Double.NaN).property("prop17", -4.373267040890351e+18).property("prop8",
>
[jira] [Updated] (TINKERPOP-2877) The incorrect result caused by long integer overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2877:
-
Fix Version/s: 4.0.0
> The incorrect result caused by long integer overflows
> -
>
> Key: TINKERPOP-2877
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2877
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
> Fix For: 4.0.0
>
>
> {code:java}
> Gremlin1:
> g.V().both().both().both().both().both().both().values('prop9').sum()
> Result1: -5308416236269507008
> Gremlin2:
> g.V().both().both().both().both().both().both().has('prop2').values('prop9').sum()
> Result2: 756493433251093
> Gremlin3:
> g.V().both().both().both().both().both().both().hasNot('prop2').values('prop9').sum()
> Result3: -8222751935482731416{code}
> We execute the above gremlin queries: Result1 should equal the sum of Result2
> and Result3, whereas -5308416236269507008 ≠756493433251093 +
> -8222751935482731416.
> The possible reason is that long integer overflows happen in the process.
> Could you return an exception to notify the user when the overflow occurs, or
> use BigDecimal during the procedure?
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
> Double.NaN).property("prop17", -4.373267040890351e+18).property("prop8",
>
[jira] [Updated] (TINKERPOP-3016) TinkerTransactionGraph can incorrectly handle some read operations.
[ https://issues.apache.org/jira/browse/TINKERPOP-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-3016: - Fix Version/s: 3.7.1 > TinkerTransactionGraph can incorrectly handle some read operations. > --- > > Key: TINKERPOP-3016 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3016 > Project: TinkerPop > Issue Type: Bug > Components: tinkergraph >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.7.1 > > > With some combination of reading operations, `TinkerTransactionGraph` may > return not the current Element value, but the cached one. > This may also cause update operations to fail with `Conflict: element > modified in another transaction` exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-3016) TinkerTransactionGraph can incorrectly handle some read operations.
[ https://issues.apache.org/jira/browse/TINKERPOP-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-3016. Resolution: Fixed > TinkerTransactionGraph can incorrectly handle some read operations. > --- > > Key: TINKERPOP-3016 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3016 > Project: TinkerPop > Issue Type: Bug > Components: tinkergraph >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.7.1 > > > With some combination of reading operations, `TinkerTransactionGraph` may > return not the current Element value, but the cached one. > This may also cause update operations to fail with `Conflict: element > modified in another transaction` exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3015) Use wildcard instead of Object for hasId predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-3015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17786480#comment-17786480
]
Valentyn Kahamlyk commented on TINKERPOP-3015:
--
Could you share code example with compilation error?
For me works without issues with latest 3.6.x and 3.7.x
{code:java}
Graph graph = TinkerFactory.createModern();
GraphTraversalSource g = graph.traversal();
Collection ids = Arrays.asList("1","2","3");
List vertices = g.V().hasId(P.within(ids)).toList();
System.out.println(vertices);{code}
> Use wildcard instead of Object for hasId predicates
> ---
>
> Key: TINKERPOP-3015
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3015
> Project: TinkerPop
> Issue Type: Improvement
>Affects Versions: 3.5.7, 3.6.5
>Reporter: Christopher Smith
>Priority: Minor
>
> From both {{GraphTraversal}} and {{__}}, the {{hasId(P)}} steps specify a
> {{P}}. Common predicates, such as {{within}}, propagate the generic
> type from their own arguments, so that this produces a compile-time error:
> {code}
> Collection ids = ...
> g.V().hasId(P.within(ids))
> {code}
> I believe that without loss of safety, the signature in both locations could
> be changed to {{P}}, making the typical case of "here's a collection of
> IDs of known type" work smoothly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-3016) TinkerTransactionGraph can incorrectly handle some read operations.
[ https://issues.apache.org/jira/browse/TINKERPOP-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk reassigned TINKERPOP-3016: Assignee: Valentyn Kahamlyk > TinkerTransactionGraph can incorrectly handle some read operations. > --- > > Key: TINKERPOP-3016 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3016 > Project: TinkerPop > Issue Type: Bug > Components: tinkergraph >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Assignee: Valentyn Kahamlyk >Priority: Critical > > With some combination of reading operations, `TinkerTransactionGraph` may > return not the current Element value, but the cached one. > This may also cause update operations to fail with `Conflict: element > modified in another transaction` exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3016) TinkerTransactionGraph can incorrectly handle some read operations.
Valentyn Kahamlyk created TINKERPOP-3016: Summary: TinkerTransactionGraph can incorrectly handle some read operations. Key: TINKERPOP-3016 URL: https://issues.apache.org/jira/browse/TINKERPOP-3016 Project: TinkerPop Issue Type: Bug Components: tinkergraph Affects Versions: 3.7.0 Reporter: Valentyn Kahamlyk With some combination of reading operations, `TinkerTransactionGraph` may return not the current Element value, but the cached one. This may also cause update operations to fail with `Conflict: element modified in another transaction` exception. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2877) The incorrect result caused by long integer overflows
[
https://issues.apache.org/jira/browse/TINKERPOP-2877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2877:
Assignee: Valentyn Kahamlyk
> The incorrect result caused by long integer overflows
> -
>
> Key: TINKERPOP-2877
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2877
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
>
> {code:java}
> Gremlin1:
> g.V().both().both().both().both().both().both().values('prop9').sum()
> Result1: -5308416236269507008
> Gremlin2:
> g.V().both().both().both().both().both().both().has('prop2').values('prop9').sum()
> Result2: 756493433251093
> Gremlin3:
> g.V().both().both().both().both().both().both().hasNot('prop2').values('prop9').sum()
> Result3: -8222751935482731416{code}
> We execute the above gremlin queries: Result1 should equal the sum of Result2
> and Result3, whereas -5308416236269507008 ≠756493433251093 +
> -8222751935482731416.
> The possible reason is that long integer overflows happen in the process.
> Could you return an exception to notify the user when the overflow occurs, or
> use BigDecimal during the procedure?
> The graph is created by the following statements:
> {code:java}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
> Double.NaN).property("prop17", -4.373267040890351e+18).property("prop8",
>
[jira] [Closed] (TINKERPOP-2996) Golang Translator in core does not properly translate list arguments
[
https://issues.apache.org/jira/browse/TINKERPOP-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2996.
Resolution: Fixed
> Golang Translator in core does not properly translate list arguments
>
>
> Key: TINKERPOP-2996
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2996
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.7.0, 3.5.7, 3.6.5
>Reporter: Yang Xia
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.6.6, 3.7.1, 4.0.0
>
>
> Currently for the bytecode translatro in core, all list type arguments are
> translated as varargs for golang, instead of proper list type like
> []interface{}{}.
> Currently this is causing errors in certain translations, i.e. g.inject([1,
> 2]) is being translated to g.Inject(1, 2), but some investigation will be
> needed to tease apart cases that may need a varargs argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2996) Golang Translator in core does not properly translate list arguments
[
https://issues.apache.org/jira/browse/TINKERPOP-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2996:
Assignee: Valentyn Kahamlyk
> Golang Translator in core does not properly translate list arguments
>
>
> Key: TINKERPOP-2996
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2996
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.7.0, 3.5.7, 3.6.5
>Reporter: Yang Xia
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.6.6, 3.7.1, 4.0.0
>
>
> Currently for the bytecode translatro in core, all list type arguments are
> translated as varargs for golang, instead of proper list type like
> []interface{}{}.
> Currently this is causing errors in certain translations, i.e. g.inject([1,
> 2]) is being translated to g.Inject(1, 2), but some investigation will be
> needed to tease apart cases that may need a varargs argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2996) Golang Translator in core does not properly translate list arguments
[
https://issues.apache.org/jira/browse/TINKERPOP-2996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2996:
-
Fix Version/s: 3.6.6
3.7.1
4.0.0
> Golang Translator in core does not properly translate list arguments
>
>
> Key: TINKERPOP-2996
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2996
> Project: TinkerPop
> Issue Type: Bug
> Components: go
>Affects Versions: 3.7.0, 3.5.7, 3.6.5
>Reporter: Yang Xia
>Priority: Critical
> Fix For: 3.6.6, 3.7.1, 4.0.0
>
>
> Currently for the bytecode translatro in core, all list type arguments are
> translated as varargs for golang, instead of proper list type like
> []interface{}{}.
> Currently this is causing errors in certain translations, i.e. g.inject([1,
> 2]) is being translated to g.Inject(1, 2), but some investigation will be
> needed to tease apart cases that may need a varargs argument.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2879) java.lang.NumberFormatException triggered by comparing with INFINITY
[
https://issues.apache.org/jira/browse/TINKERPOP-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2879:
Assignee: Valentyn Kahamlyk
> java.lang.NumberFormatException triggered by comparing with INFINITY
>
>
> Key: TINKERPOP-2879
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2879
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Assignee: Valentyn Kahamlyk
>Priority: Critical
>
> We execute two gremlin queries, where the first one correctly return the
> result and the second one return an unexpected exception:
> _java.lang.NumberFormatException_
> {code:java}
> Gremlin1:
> g.E().where(__.values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result1: 6
> Gremlin2:
> g.E().where(__.bothV().values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result2: java.lang.NumberFormatException{code}
> The graph (5 vertices, 30 edges) is created by the following statements:
> {code}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
> Double.NaN).property("prop17", -4.373267040890351e+18).property("prop8",
> Double.NEGATIVE_INFINITY).property("prop22", Double.NaN).property("prop14",
> Double.NaN).property("PersonalId", 6)g.addV("Vlabel3").property("prop13",
> -1952583718).property("prop11", false).property("prop20",
>
[jira] [Closed] (TINKERPOP-2879) java.lang.NumberFormatException triggered by comparing with INFINITY
[
https://issues.apache.org/jira/browse/TINKERPOP-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2879.
Resolution: Won't Fix
> java.lang.NumberFormatException triggered by comparing with INFINITY
>
>
> Key: TINKERPOP-2879
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2879
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Assignee: Valentyn Kahamlyk
>Priority: Critical
>
> We execute two gremlin queries, where the first one correctly return the
> result and the second one return an unexpected exception:
> _java.lang.NumberFormatException_
> {code:java}
> Gremlin1:
> g.E().where(__.values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result1: 6
> Gremlin2:
> g.E().where(__.bothV().values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result2: java.lang.NumberFormatException{code}
> The graph (5 vertices, 30 edges) is created by the following statements:
> {code}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
> 2.21716537881794e+18).property("prop14",
> Double.POSITIVE_INFINITY).property("PersonalId",
> 5)g.addV("Vlabel5").property("prop6", "cBao").property("prop26",
> -5.21685685375749e+18).property("prop30", 1375392625).property("prop27",
> 429620057).property("prop7", false).property("prop16",
> 1535367691959044.0).property("prop13", 1046501670).property("prop11",
> false).property("prop1", -7972953637432281761).property("prop15",
> Double.NaN).property("prop17", -4.373267040890351e+18).property("prop8",
> Double.NEGATIVE_INFINITY).property("prop22", Double.NaN).property("prop14",
> Double.NaN).property("PersonalId", 6)g.addV("Vlabel3").property("prop13",
> -1952583718).property("prop11", false).property("prop20",
>
[jira] [Comment Edited] (TINKERPOP-2879) java.lang.NumberFormatException triggered by comparing with INFINITY
[
https://issues.apache.org/jira/browse/TINKERPOP-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781099#comment-17781099
]
Valentyn Kahamlyk edited comment on TINKERPOP-2879 at 10/30/23 7:33 PM:
By default, Groovy uses `BigDecimal` type to store floating point numbers.
{code:java}
gremlin> (1.0).class
==>class java.math.BigDecimal{code}
There is no Infinity concept for this type.
When performing arithmetic operations, all arguments are cast to a common type,
which in the case of queries like
{code:java}
__.inject(Double.NEGATIVE_INFINITY, 1.0).sum(){code}
will be `BigDecimal` because 1.0 is `BigDecimal`.
When trying to convert `Double.NEGATIVE_INFINITY` to `BigDecimal` we get an
error `NumberFormatException`. More details about conversion in java source
code for `BigDecimal.valueOf(double val)`
For such queries to work correctly, you must explicitly indicate that the
arguments are of type `Double`, for example
{code:java}
gremlin> __.inject(Double.NEGATIVE_INFINITY, 1.0d).sum()
==>-Infinity{code}
was (Author: JIRAUSER295200):
By default, Groovy uses `BigDecimal` type to store floating point numbers.
`gremlin> (1.0).class
==>class java.math.BigDecimal`
There is no Infinity concept for this type.
When performing arithmetic operations, all arguments are cast to a common type,
which in the case of queries like
` __.inject(Double.NEGATIVE_INFINITY, 1.0).sum()`
will be `BigDecimal` because 1.0 is `BigDecimal`.
When trying to convert `Double.NEGATIVE_INFINITY` to `BigDecimal` we get an
error `NumberFormatException`. More details about conversion in java source
code for `BigDecimal.valueOf(double val)`
For such queries to work correctly, you must explicitly indicate that the
arguments are of type `Double`, for example
`gremlin> __.inject(Double.NEGATIVE_INFINITY, 1.0d).sum()
==>-Infinity`
> java.lang.NumberFormatException triggered by comparing with INFINITY
>
>
> Key: TINKERPOP-2879
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2879
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Critical
>
> We execute two gremlin queries, where the first one correctly return the
> result and the second one return an unexpected exception:
> _java.lang.NumberFormatException_
> {code:java}
> Gremlin1:
> g.E().where(__.values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result1: 6
> Gremlin2:
> g.E().where(__.bothV().values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result2: java.lang.NumberFormatException{code}
> The graph (5 vertices, 30 edges) is created by the following statements:
> {code}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
>
[jira] [Commented] (TINKERPOP-2879) java.lang.NumberFormatException triggered by comparing with INFINITY
[
https://issues.apache.org/jira/browse/TINKERPOP-2879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17781099#comment-17781099
]
Valentyn Kahamlyk commented on TINKERPOP-2879:
--
By default, Groovy uses `BigDecimal` type to store floating point numbers.
`gremlin> (1.0).class
==>class java.math.BigDecimal`
There is no Infinity concept for this type.
When performing arithmetic operations, all arguments are cast to a common type,
which in the case of queries like
` __.inject(Double.NEGATIVE_INFINITY, 1.0).sum()`
will be `BigDecimal` because 1.0 is `BigDecimal`.
When trying to convert `Double.NEGATIVE_INFINITY` to `BigDecimal` we get an
error `NumberFormatException`. More details about conversion in java source
code for `BigDecimal.valueOf(double val)`
For such queries to work correctly, you must explicitly indicate that the
arguments are of type `Double`, for example
`gremlin> __.inject(Double.NEGATIVE_INFINITY, 1.0d).sum()
==>-Infinity`
> java.lang.NumberFormatException triggered by comparing with INFINITY
>
>
> Key: TINKERPOP-2879
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2879
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.2
>Reporter: Miracy Cavendish
>Priority: Critical
>
> We execute two gremlin queries, where the first one correctly return the
> result and the second one return an unexpected exception:
> _java.lang.NumberFormatException_
> {code:java}
> Gremlin1:
> g.E().where(__.values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result1: 6
> Gremlin2:
> g.E().where(__.bothV().values("prop16").sum().is(inside(Double.NEGATIVE_INFINITY,
> Double.POSITIVE_INFINITY))).inV().count()
> Result2: java.lang.NumberFormatException{code}
> The graph (5 vertices, 30 edges) is created by the following statements:
> {code}
> g.addV("Vlabel1").property("prop11", true).property("prop26",
> -1.3054643785208727e+18).property("prop3",
> 5955883311802481410).property("PersonalId", 1)
> g.addV("Vlabel2").property("prop23", 1013597808).property("prop14",
> Double.POSITIVE_INFINITY).property("prop29",
> -8.088511244487521e+18).property("prop1",
> -791166414100353228).property("prop10", Double.NaN).property("prop20",
> false).property("prop12", -1.611044197269977e+18).property("prop8",
> Double.POSITIVE_INFINITY).property("prop28",
> "r8OwmXN0z4xVA32DuW").property("prop7", true).property("prop18",
> 122416389).property("prop4", -133008224708918302).property("prop16",
> Double.POSITIVE_INFINITY).property("prop5",
> 2.199870305073074e+18).property("prop30", 1951661449).property("PersonalId",
> 2)
> g.addV("Vlabel3").property("prop13", -1833987394).property("prop11",
> false).property("prop20", true).property("prop28", "Eb").property("prop26",
> Double.POSITIVE_INFINITY).property("prop19",
> "fkOMPiHGK4Qh9AEt").property("prop4", 7223784666736222475).property("prop21",
> "emdyKI4gibcntwr9xr1R").property("prop8",
> 1.6766837870245322e+18).property("prop6",
> "KPvJU8zUZkDujXO5").property("prop5",
> Double.POSITIVE_INFINITY).property("prop16",
> Double.NEGATIVE_INFINITY).property("prop29",
> -6.379213156782167e+16).property("prop9",
> -2639063587618099127).property("prop2",
> -4223871862589164789).property("prop7", true).property("prop22",
> 3.3866441258784246e+18).property("prop12",
> Double.NEGATIVE_INFINITY).property("prop15",
> Double.POSITIVE_INFINITY).property("prop27", -811138702).property("prop18",
> -823086061).property("prop30", 1766879986).property("prop10",
> Double.NEGATIVE_INFINITY).property("prop25", true).property("prop17",
> -7.221182960918364e+17).property("prop3",
> 3709150069759562136).property("prop24", true).property("prop23",
> 2089722858).property("prop1", 4952669033574350283).property("PersonalId", 3)
> g.addV("Vlabel4").property("prop18", 1921954359).property("prop9",
> 3679390972557414017).property("prop28", "zea").property("prop5",
> -5.37655340395617e+18).property("prop23", 873631855).property("prop29",
> -4.730510618138025e+18).property("prop13", 262081621).property("prop27",
> 954111430).property("prop25", true).property("prop7",
> false).property("prop12", Double.POSITIVE_INFINITY).property("prop24",
> false).property("PersonalId", 4)
> g.addV("Vlabel5").property("prop6", "BaCsHhoMCngKebN").property("prop26",
> Double.NEGATIVE_INFINITY).property("prop30", -1093199590).property("prop27",
> -761660443).property("prop7", false).property("prop16",
> -3.702472520864335e+18).property("prop13", -1871493760).property("prop11",
> true).property("prop1", 3729131191884336357).property("prop15",
> -1.6551486100927974e+17).property("prop17", Double.NaN).property("prop8",
> Double.POSITIVE_INFINITY).property("prop22",
[jira] [Closed] (TINKERPOP-2334) Add format() step
[
https://issues.apache.org/jira/browse/TINKERPOP-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2334.
Fix Version/s: 3.7.1
Resolution: Fixed
> Add format() step
> -
>
> Key: TINKERPOP-2334
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2334
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.4
>Reporter: Stephen Mallette
>Assignee: Valentyn Kahamlyk
>Priority: Major
> Fix For: 3.7.1
>
>
> Provide for a {{format()}} step which will handle result formatting to string
> values. This change will help resolve the need for string concatenation
> functions while providing a lot of flexibility to how results can be formed:
> {code}
> gremlin> g.V().hasLabel('person').format("%{n} is %{a} years old.").by('n',
> 'name').by('a', 'age')
> ==>marko is 29 years old.
> ==>vadas is 27 years old.
> ==>josh is 32 years old.
> ==>peter is 35 years old.
> gremlin> g.V().hasLabel('person').format("%{name} is %{age} years old.")
> ==>marko is 29 years old.
> ==>vadas is 27 years old.
> ==>josh is 32 years old.
> ==>peter is 35 years old.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2964. Resolution: Fixed > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.6.6, 3.7.1 > > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk reopened TINKERPOP-2964: -- > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.7.1 > > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2964: - Fix Version/s: 3.6.6 > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.6.6, 3.7.1 > > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2962) Exception Handling in Multi-Value Key Scenario for TinkerPop
[ https://issues.apache.org/jira/browse/TINKERPOP-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk resolved TINKERPOP-2962. -- Resolution: Won't Fix > Exception Handling in Multi-Value Key Scenario for TinkerPop > > > Key: TINKERPOP-2962 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2962 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.5.6 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > > The current implementation of multi-label behavior in TinkerPop results in > exceptions when a vertex has multiple values for one key. This issue is > evidenced in this code snippet: > [https://github.com/apache/tinkerpop/blob/db3933f229350c83b90a2c83bb7c35b6be35ca0a/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerVertex.java#L72+L77] > Instead of throwing an exception in such cases, it's proposed to change the > approach and initially use the 'properties()' function. Once this function is > called, we should retrieve only the first solution, irrespective of the > number of properties found. This modification aims to improve consistency and > exception handling in TinkerPop's multi-label behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2962) Exception Handling in Multi-Value Key Scenario for TinkerPop
[ https://issues.apache.org/jira/browse/TINKERPOP-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2962. > Exception Handling in Multi-Value Key Scenario for TinkerPop > > > Key: TINKERPOP-2962 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2962 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.5.6 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > > The current implementation of multi-label behavior in TinkerPop results in > exceptions when a vertex has multiple values for one key. This issue is > evidenced in this code snippet: > [https://github.com/apache/tinkerpop/blob/db3933f229350c83b90a2c83bb7c35b6be35ca0a/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerVertex.java#L72+L77] > Instead of throwing an exception in such cases, it's proposed to change the > approach and initially use the 'properties()' function. Once this function is > called, we should retrieve only the first solution, irrespective of the > number of properties found. This modification aims to improve consistency and > exception handling in TinkerPop's multi-label behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2962) Exception Handling in Multi-Value Key Scenario for TinkerPop
[ https://issues.apache.org/jira/browse/TINKERPOP-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780091#comment-17780091 ] Valentyn Kahamlyk commented on TINKERPOP-2962: -- For Vertex with multiproperties ` Vertex.properties()` should be used instead. > Exception Handling in Multi-Value Key Scenario for TinkerPop > > > Key: TINKERPOP-2962 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2962 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.5.6 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > > The current implementation of multi-label behavior in TinkerPop results in > exceptions when a vertex has multiple values for one key. This issue is > evidenced in this code snippet: > [https://github.com/apache/tinkerpop/blob/db3933f229350c83b90a2c83bb7c35b6be35ca0a/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerVertex.java#L72+L77] > Instead of throwing an exception in such cases, it's proposed to change the > approach and initially use the 'properties()' function. Once this function is > called, we should retrieve only the first solution, irrespective of the > number of properties found. This modification aims to improve consistency and > exception handling in TinkerPop's multi-label behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2964. > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.7.1 > > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk resolved TINKERPOP-2964. -- Resolution: Fixed > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.7.1 > > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2964: - Fix Version/s: 3.7.1 > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > Fix For: 3.7.1 > > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2962) Exception Handling in Multi-Value Key Scenario for TinkerPop
[ https://issues.apache.org/jira/browse/TINKERPOP-2962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk reassigned TINKERPOP-2962: Assignee: Valentyn Kahamlyk > Exception Handling in Multi-Value Key Scenario for TinkerPop > > > Key: TINKERPOP-2962 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2962 > Project: TinkerPop > Issue Type: Improvement > Components: structure >Affects Versions: 3.5.6 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > > The current implementation of multi-label behavior in TinkerPop results in > exceptions when a vertex has multiple values for one key. This issue is > evidenced in this code snippet: > [https://github.com/apache/tinkerpop/blob/db3933f229350c83b90a2c83bb7c35b6be35ca0a/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerVertex.java#L72+L77] > Instead of throwing an exception in such cases, it's proposed to change the > approach and initially use the 'properties()' function. Once this function is > called, we should retrieve only the first solution, irrespective of the > number of properties found. This modification aims to improve consistency and > exception handling in TinkerPop's multi-label behavior. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2964) Many TraversalParent's steps have a replaceLocalChild logic that can result in a new ChildTraversal having an ID that already exists.
[ https://issues.apache.org/jira/browse/TINKERPOP-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk reassigned TINKERPOP-2964: Assignee: Valentyn Kahamlyk > Many TraversalParent's steps have a replaceLocalChild logic that can result > in a new ChildTraversal having an ID that already exists. > -- > > Key: TINKERPOP-2964 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2964 > Project: TinkerPop > Issue Type: Improvement > Components: process >Affects Versions: 3.6.0 >Reporter: Jianzhong Liu >Assignee: Valentyn Kahamlyk >Priority: Critical > > Following the invocation of replaceLocalChild, the new childTraversal within > many steps can have an ID that already exists. For instance, in the TreeStep > traversal ring replace logic, the 'integrateChild' function should be called > prior to assigning it the new traversal. More details can be found in the > Apache TinkerPop code at this link: > [https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/TreeStep.java#L68-L72.] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2334) Add format() step
[
https://issues.apache.org/jira/browse/TINKERPOP-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2334:
Assignee: Valentyn Kahamlyk
> Add format() step
> -
>
> Key: TINKERPOP-2334
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2334
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.4
>Reporter: Stephen Mallette
>Assignee: Valentyn Kahamlyk
>Priority: Major
>
> Provide for a {{format()}} step which will handle result formatting to string
> values. This change will help resolve the need for string concatenation
> functions while providing a lot of flexibility to how results can be formed:
> {code}
> gremlin> g.V().hasLabel('person').format("%{n} is %{a} years old.").by('n',
> 'name').by('a', 'age')
> ==>marko is 29 years old.
> ==>vadas is 27 years old.
> ==>josh is 32 years old.
> ==>peter is 35 years old.
> gremlin> g.V().hasLabel('person').format("%{name} is %{age} years old.")
> ==>marko is 29 years old.
> ==>vadas is 27 years old.
> ==>josh is 32 years old.
> ==>peter is 35 years old.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3004) Low performance for queries with a large number of element comparisons
Valentyn Kahamlyk created TINKERPOP-3004: Summary: Low performance for queries with a large number of element comparisons Key: TINKERPOP-3004 URL: https://issues.apache.org/jira/browse/TINKERPOP-3004 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.7.0 Reporter: Valentyn Kahamlyk There is a query where need to find except of two sets of vertices using `P.without`. Performance dropped significantly when moving from 3.5 to 3.7. Rough estimate is at least 2 times. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (TINKERPOP-2979) Add Date Manipulation Steps to Gremlin
[ https://issues.apache.org/jira/browse/TINKERPOP-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk resolved TINKERPOP-2979. -- Resolution: Implemented > Add Date Manipulation Steps to Gremlin > -- > > Key: TINKERPOP-2979 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2979 > Project: TinkerPop > Issue Type: Improvement > Components: language >Reporter: Cole Greer >Assignee: Valentyn Kahamlyk >Priority: Major > Fix For: 3.7.1 > > > Today Gremlin requires that users fall back to closures to handle many common > date manipulation options that users want to do on data in the graph. This > is a problem for many users as many of the providers prevent the use of > closures due to the security risks so for these users there is no way to > manipulate dates directly. > A full list of proposed functions and semantics is detailed here: > [https://github.com/apache/tinkerpop/blob/3.7.0/docs/src/dev/future/proposal-3-remove-closures.asciidoc] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2979) Add Date Manipulation Steps to Gremlin
[ https://issues.apache.org/jira/browse/TINKERPOP-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2979. > Add Date Manipulation Steps to Gremlin > -- > > Key: TINKERPOP-2979 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2979 > Project: TinkerPop > Issue Type: Improvement > Components: language >Reporter: Cole Greer >Assignee: Valentyn Kahamlyk >Priority: Major > Fix For: 3.7.1 > > > Today Gremlin requires that users fall back to closures to handle many common > date manipulation options that users want to do on data in the graph. This > is a problem for many users as many of the providers prevent the use of > closures due to the security risks so for these users there is no way to > manipulate dates directly. > A full list of proposed functions and semantics is detailed here: > [https://github.com/apache/tinkerpop/blob/3.7.0/docs/src/dev/future/proposal-3-remove-closures.asciidoc] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2979) Add Date Manipulation Steps to Gremlin
[ https://issues.apache.org/jira/browse/TINKERPOP-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2979: - Fix Version/s: 3.7.1 > Add Date Manipulation Steps to Gremlin > -- > > Key: TINKERPOP-2979 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2979 > Project: TinkerPop > Issue Type: Improvement > Components: language >Reporter: Cole Greer >Assignee: Valentyn Kahamlyk >Priority: Major > Fix For: 3.7.1 > > > Today Gremlin requires that users fall back to closures to handle many common > date manipulation options that users want to do on data in the graph. This > is a problem for many users as many of the providers prevent the use of > closures due to the security risks so for these users there is no way to > manipulate dates directly. > A full list of proposed functions and semantics is detailed here: > [https://github.com/apache/tinkerpop/blob/3.7.0/docs/src/dev/future/proposal-3-remove-closures.asciidoc] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2979) Add Date Manipulation Steps to Gremlin
[ https://issues.apache.org/jira/browse/TINKERPOP-2979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk reassigned TINKERPOP-2979: Assignee: Valentyn Kahamlyk > Add Date Manipulation Steps to Gremlin > -- > > Key: TINKERPOP-2979 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2979 > Project: TinkerPop > Issue Type: Improvement > Components: language >Reporter: Cole Greer >Assignee: Valentyn Kahamlyk >Priority: Major > > Today Gremlin requires that users fall back to closures to handle many common > date manipulation options that users want to do on data in the graph. This > is a problem for many users as many of the providers prevent the use of > closures due to the security risks so for these users there is no way to > manipulate dates directly. > A full list of proposed functions and semantics is detailed here: > [https://github.com/apache/tinkerpop/blob/3.7.0/docs/src/dev/future/proposal-3-remove-closures.asciidoc] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (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
]
Valentyn Kahamlyk closed TINKERPOP-2939.
Resolution: Fixed
> 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
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.7.0, 3.6.5
>
>
> 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-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
]
Valentyn Kahamlyk updated TINKERPOP-2939:
-
Fix Version/s: 3.7.0
3.6.5
> 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
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.7.0, 3.6.5
>
>
> 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] [Reopened] (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
]
Valentyn Kahamlyk reopened TINKERPOP-2939:
--
Assignee: Valentyn Kahamlyk
> 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
>Assignee: Valentyn Kahamlyk
>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] [Closed] (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
]
Valentyn Kahamlyk closed TINKERPOP-2939.
Resolution: Fixed
> 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] [Closed] (TINKERPOP-2975) Native transaction support for Tinkerpop
[ https://issues.apache.org/jira/browse/TINKERPOP-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2975. Resolution: Done > Native transaction support for Tinkerpop > > > Key: TINKERPOP-2975 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2975 > Project: TinkerPop > Issue Type: New Feature > Components: process >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Priority: Major > > Implement transactions according to [design > proposal|https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-transaction-4.asciidoc] > and [DISCUSS > thread|https://lists.apache.org/thread/bynoh8o65lw4jw8r73vp0mgmndyr9knk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2975) Native transaction support for Tinkerpop
[ https://issues.apache.org/jira/browse/TINKERPOP-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2975: - Issue Type: New Feature (was: Bug) > Native transaction support for Tinkerpop > > > Key: TINKERPOP-2975 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2975 > Project: TinkerPop > Issue Type: New Feature > Components: process >Affects Versions: 3.7.0 >Reporter: Valentyn Kahamlyk >Priority: Major > > Implement transactions according to [design > proposal|https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-transaction-4.asciidoc] > and [DISCUSS > thread|https://lists.apache.org/thread/bynoh8o65lw4jw8r73vp0mgmndyr9knk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2975) Native transaction support for Tinkerpop
Valentyn Kahamlyk created TINKERPOP-2975: Summary: Native transaction support for Tinkerpop Key: TINKERPOP-2975 URL: https://issues.apache.org/jira/browse/TINKERPOP-2975 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.7.0 Reporter: Valentyn Kahamlyk Implement transactions according to [design proposal|https://github.com/apache/tinkerpop/blob/master/docs/src/dev/future/proposal-transaction-4.asciidoc] and [DISCUSS thread|https://lists.apache.org/thread/bynoh8o65lw4jw8r73vp0mgmndyr9knk] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2974) `valueMap` step returns properties in random order
Valentyn Kahamlyk created TINKERPOP-2974:
Summary: `valueMap` step returns properties in random order
Key: TINKERPOP-2974
URL: https://issues.apache.org/jira/browse/TINKERPOP-2974
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.6.4, 3.5.6
Reporter: Valentyn Kahamlyk
`valueMap` step return properties in random order. In most cases it's not
important, but
but for example this does not allow using `by` modulators correctly.
In this example I expect to get `name` unfolded, but modulator applied to
`location`
{code:java}
gremlin> g = TinkerFactory.createTheCrew().traversal()
==>graphtraversalsource[tinkergraph[vertices:6 edges:14], standard]
gremlin> g.V(1).valueMap("location","name").by().by(__.unfold())
==>[name:[marko],location:san diego]{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2949) More strict handling of predicates
[ https://issues.apache.org/jira/browse/TINKERPOP-2949?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2949. Fix Version/s: 3.7.0 Resolution: Done > 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 > Fix For: 3.7.0 > > > 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] [Created] (TINKERPOP-2970) Always correctly close CloseableIterator
Valentyn Kahamlyk created TINKERPOP-2970: Summary: Always correctly close CloseableIterator Key: TINKERPOP-2970 URL: https://issues.apache.org/jira/browse/TINKERPOP-2970 Project: TinkerPop Issue Type: Bug Components: process Affects Versions: 3.6.4, 3.5.6 Reporter: Valentyn Kahamlyk In some cases `CloseableIterator`s not closed correctly. Need to check all usages and explicitly call `CloseableIterator.closeIterator` -- 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 ] Valentyn Kahamlyk updated TINKERPOP-2872: - Priority: Major (was: Critical) > 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: Major > > In most GLV's we consider Elements the same when they have the same ID. > In JavaScript tests 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-2872) Inconsistency in comparing Elements in JavaScript tests
[ https://issues.apache.org/jira/browse/TINKERPOP-2872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17742947#comment-17742947 ] Valentyn Kahamlyk commented on TINKERPOP-2872: -- the problem is only with tests and it takes time to fix it, so for now I reduce the priority > 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 tests 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] [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 ] Valentyn Kahamlyk updated TINKERPOP-2872: - Description: In most GLV's we consider Elements the same when they have the same ID. In JavaScript tests 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. was: 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. > 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 tests 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] [Created] (TINKERPOP-2960) Error handling Index with null property values
Valentyn Kahamlyk created TINKERPOP-2960: Summary: Error handling Index with null property values Key: TINKERPOP-2960 URL: https://issues.apache.org/jira/browse/TINKERPOP-2960 Project: TinkerPop Issue Type: Bug Components: tinkergraph Affects Versions: 3.6.4, 3.5.6 Reporter: Valentyn Kahamlyk TinkerGraph with enabled null properties (config option ` GREMLIN_TINKERGRAPH_ALLOW_NULL_PROPERTY_VALUES`) does not work correctly with indexes. The problem occurs when property with null value is indexed, [because IndexedNull should be used|https://github.com/apache/tinkerpop/blob/3.5-dev/tinkergraph-gremlin/src/main/java/org/apache/tinkerpop/gremlin/tinkergraph/structure/TinkerIndex.java#LL57C2-L60C2] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2941) DO NOT purge the output location if it has content in SparkGraphComputer
[ https://issues.apache.org/jira/browse/TINKERPOP-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2941: - Component/s: sparql > DO NOT purge the output location if it has content in SparkGraphComputer > > > Key: TINKERPOP-2941 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2941 > Project: TinkerPop > Issue Type: Improvement > Components: sparql >Affects Versions: 3.6.2 >Reporter: Redriver >Priority: Major > Fix For: 3.6.5 > > > The default logic for SparkGraphComputer is to purge all content if the > output location is specified. That is a dangerous operation especially for > the output location which contains contents. > https://github.com/apache/tinkerpop/blob/master/spark-gremlin/src/main/java/org/apache/tinkerpop/gremlin/spark/process/computer/SparkGraphComputer.java#L317:L324 > The correct behavior is to stop the process if it detects the output location > is not empty. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2941) DO NOT purge the output location if it has content in SparkGraphComputer
[ https://issues.apache.org/jira/browse/TINKERPOP-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2941. Resolution: Fixed > DO NOT purge the output location if it has content in SparkGraphComputer > > > Key: TINKERPOP-2941 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2941 > Project: TinkerPop > Issue Type: Improvement > Components: sparql >Affects Versions: 3.6.2 >Reporter: Redriver >Priority: Major > Fix For: 3.6.5 > > > The default logic for SparkGraphComputer is to purge all content if the > output location is specified. That is a dangerous operation especially for > the output location which contains contents. > https://github.com/apache/tinkerpop/blob/master/spark-gremlin/src/main/java/org/apache/tinkerpop/gremlin/spark/process/computer/SparkGraphComputer.java#L317:L324 > The correct behavior is to stop the process if it detects the output location > is not empty. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2941) DO NOT purge the output location if it has content in SparkGraphComputer
[ https://issues.apache.org/jira/browse/TINKERPOP-2941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2941: - Fix Version/s: 3.6.5 > DO NOT purge the output location if it has content in SparkGraphComputer > > > Key: TINKERPOP-2941 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2941 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.6.2 >Reporter: Redriver >Priority: Major > Fix For: 3.6.5 > > > The default logic for SparkGraphComputer is to purge all content if the > output location is specified. That is a dangerous operation especially for > the output location which contains contents. > https://github.com/apache/tinkerpop/blob/master/spark-gremlin/src/main/java/org/apache/tinkerpop/gremlin/spark/process/computer/SparkGraphComputer.java#L317:L324 > The correct behavior is to stop the process if it detects the output location > is not empty. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-2951) Add translator to the Go GLV
Valentyn Kahamlyk created TINKERPOP-2951: Summary: Add translator to the Go GLV Key: TINKERPOP-2951 URL: https://issues.apache.org/jira/browse/TINKERPOP-2951 Project: TinkerPop Issue Type: Improvement Components: go Affects Versions: 3.6.4, 3.5.6 Reporter: Valentyn Kahamlyk Currently there is no equivalent to GroovyTranslator for the Go client. There are Translator's in all other GLV's. Adding one for the Go client will further help in moving all the clients to a consistent level of functionality. https://tinkerpop.apache.org/docs/current/reference/#translators -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2945) TextP.regex() Serialization Failing in Java driver
[
https://issues.apache.org/jira/browse/TINKERPOP-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2945:
-
Fix Version/s: 3.6.4
> TextP.regex() Serialization Failing in Java driver
> --
>
> Key: TINKERPOP-2945
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2945
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.7.0, 3.6.3
>Reporter: Yang Xia
>Priority: Critical
> Fix For: 3.6.4
>
>
> The serialization for TextP.regex() is failing in Java for both GraphBinary
> and GraphSON.
> To reproduce, add
> {code:java}
> new Object[] {"TextP", TextP.regex("^meh"), null}, {code}
> into the argument list for GraphBinaryReaderWriterRoundTripTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2945) TextP.regex() Serialization Failing in Java driver
[
https://issues.apache.org/jira/browse/TINKERPOP-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2945:
-
Fix Version/s: 3.7.0
> TextP.regex() Serialization Failing in Java driver
> --
>
> Key: TINKERPOP-2945
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2945
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.3
>Reporter: Yang Xia
>Priority: Critical
> Fix For: 3.7.0, 3.6.4
>
>
> The serialization for TextP.regex() is failing in Java for both GraphBinary
> and GraphSON.
> To reproduce, add
> {code:java}
> new Object[] {"TextP", TextP.regex("^meh"), null}, {code}
> into the argument list for GraphBinaryReaderWriterRoundTripTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2945) TextP.regex() Serialization Failing in Java driver
[
https://issues.apache.org/jira/browse/TINKERPOP-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2945.
Resolution: Fixed
> TextP.regex() Serialization Failing in Java driver
> --
>
> Key: TINKERPOP-2945
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2945
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.3
>Reporter: Yang Xia
>Priority: Critical
> Fix For: 3.7.0, 3.6.4
>
>
> The serialization for TextP.regex() is failing in Java for both GraphBinary
> and GraphSON.
> To reproduce, add
> {code:java}
> new Object[] {"TextP", TextP.regex("^meh"), null}, {code}
> into the argument list for GraphBinaryReaderWriterRoundTripTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2945) TextP.regex() Serialization Failing in Java driver
[
https://issues.apache.org/jira/browse/TINKERPOP-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2945:
-
Affects Version/s: (was: 3.7.0)
> TextP.regex() Serialization Failing in Java driver
> --
>
> Key: TINKERPOP-2945
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2945
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.3
>Reporter: Yang Xia
>Priority: Critical
> Fix For: 3.6.4
>
>
> The serialization for TextP.regex() is failing in Java for both GraphBinary
> and GraphSON.
> To reproduce, add
> {code:java}
> new Object[] {"TextP", TextP.regex("^meh"), null}, {code}
> into the argument list for GraphBinaryReaderWriterRoundTripTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-2949) More strict handling of predicates
Valentyn Kahamlyk created TINKERPOP-2949: Summary: 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 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] [Commented] (TINKERPOP-2943) GraphBinary serialization error when vertex ID is larger than 2**31.
[
https://issues.apache.org/jira/browse/TINKERPOP-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720061#comment-17720061
]
Valentyn Kahamlyk commented on TINKERPOP-2943:
--
long is alias for int
[defined|https://github.com/apache/tinkerpop/blob/3.6-dev/gremlin-python/src/main/python/gremlin_python/statics.py#L24]
in `gremlin_python.statics`
> GraphBinary serialization error when vertex ID is larger than 2**31.
>
>
> Key: TINKERPOP-2943
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2943
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.2
> Environment: Python 3.10
>Reporter: Matthew Carr
>Priority: Major
>
> An exception occurs when using the "graphbinaryV1" serialization format and
> an attempt is made to query a vertex whose ID is larger than `2**31`. I
> encountered this issue on `gremlinpython` 3.6.2 running on Python 3.10. A
> minimal reproduction is as follows:
> ```
> from gremlin_python.driver.driver_remote_connection import
> DriverRemoteConnection
> from gremlin_python.process.anonymous_traversal import traversal
> remote = DriverRemoteConnection("ws://127.0.0.1:8182/gremlin", "g")
> g = traversal().withRemote(remote)
> g.V(2**31 + 1).next()
> ```
> This code produces the following stack trace on my machine:
> ```
> Traceback (most recent call last):
> File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
> exec(code, run_globals)
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py",
> line 39, in
> cli.main()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 430, in main
> run()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 284, in run_file
> runpy.run_path(target, run_name="__main__")
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 321, in run_path
> return _run_module_code(code, init_globals, run_name,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 135, in _run_module_code
> _run_code(code, mod_globals, init_globals,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 124, in _run_code
> exec(code, run_globals)
> File "/home/matt/Projects/tada/thermo/repro.py", line 6, in
> g.V(2**31 + 1).next()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 117, in next
> return self.__next__()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 48, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 684, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/driver_remote_connection.py",
> line 104, in submit
> result_set = self._client.submit(bytecode,
> request_options=self._extract_request_options(bytecode))
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/client.py",
> line 150, in submit
> return self.submit_async(message, bindings=bindings,
> request_options=request_options).result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 458, in result
> return self.__get_result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in
> __get_result
> raise self._exception
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/connection.py",
> line 73, in cb
> f.result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 451, in result
> return self.__get_result()
> File
[jira] [Comment Edited] (TINKERPOP-2943) GraphBinary serialization error when vertex ID is larger than 2**31.
[
https://issues.apache.org/jira/browse/TINKERPOP-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720008#comment-17720008
]
Valentyn Kahamlyk edited comment on TINKERPOP-2943 at 5/5/23 9:43 PM:
--
As an option you can try to explicitly specify the type of id:
{code:java}
g.V(long(2**31 + 1)).next(){code}
was (Author: JIRAUSER295200):
As an option you can try to explicitly specify the type of id:
`g.V(long(2**31 + 1)).next()`
> GraphBinary serialization error when vertex ID is larger than 2**31.
>
>
> Key: TINKERPOP-2943
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2943
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.2
> Environment: Python 3.10
>Reporter: Matthew Carr
>Priority: Major
>
> An exception occurs when using the "graphbinaryV1" serialization format and
> an attempt is made to query a vertex whose ID is larger than `2**31`. I
> encountered this issue on `gremlinpython` 3.6.2 running on Python 3.10. A
> minimal reproduction is as follows:
> ```
> from gremlin_python.driver.driver_remote_connection import
> DriverRemoteConnection
> from gremlin_python.process.anonymous_traversal import traversal
> remote = DriverRemoteConnection("ws://127.0.0.1:8182/gremlin", "g")
> g = traversal().withRemote(remote)
> g.V(2**31 + 1).next()
> ```
> This code produces the following stack trace on my machine:
> ```
> Traceback (most recent call last):
> File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
> exec(code, run_globals)
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py",
> line 39, in
> cli.main()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 430, in main
> run()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 284, in run_file
> runpy.run_path(target, run_name="__main__")
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 321, in run_path
> return _run_module_code(code, init_globals, run_name,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 135, in _run_module_code
> _run_code(code, mod_globals, init_globals,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 124, in _run_code
> exec(code, run_globals)
> File "/home/matt/Projects/tada/thermo/repro.py", line 6, in
> g.V(2**31 + 1).next()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 117, in next
> return self.__next__()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 48, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 684, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/driver_remote_connection.py",
> line 104, in submit
> result_set = self._client.submit(bytecode,
> request_options=self._extract_request_options(bytecode))
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/client.py",
> line 150, in submit
> return self.submit_async(message, bindings=bindings,
> request_options=request_options).result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 458, in result
> return self.__get_result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in
> __get_result
> raise self._exception
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/connection.py",
> line 73, in cb
> f.result()
> File
[jira] [Commented] (TINKERPOP-2943) GraphBinary serialization error when vertex ID is larger than 2**31.
[
https://issues.apache.org/jira/browse/TINKERPOP-2943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720008#comment-17720008
]
Valentyn Kahamlyk commented on TINKERPOP-2943:
--
As an option you can try to explicitly specify the type of id:
`g.V(long(2**31 + 1)).next()`
> GraphBinary serialization error when vertex ID is larger than 2**31.
>
>
> Key: TINKERPOP-2943
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2943
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.2
> Environment: Python 3.10
>Reporter: Matthew Carr
>Priority: Major
>
> An exception occurs when using the "graphbinaryV1" serialization format and
> an attempt is made to query a vertex whose ID is larger than `2**31`. I
> encountered this issue on `gremlinpython` 3.6.2 running on Python 3.10. A
> minimal reproduction is as follows:
> ```
> from gremlin_python.driver.driver_remote_connection import
> DriverRemoteConnection
> from gremlin_python.process.anonymous_traversal import traversal
> remote = DriverRemoteConnection("ws://127.0.0.1:8182/gremlin", "g")
> g = traversal().withRemote(remote)
> g.V(2**31 + 1).next()
> ```
> This code produces the following stack trace on my machine:
> ```
> Traceback (most recent call last):
> File "/usr/lib/python3.10/runpy.py", line 196, in _run_module_as_main
> return _run_code(code, main_globals, None,
> File "/usr/lib/python3.10/runpy.py", line 86, in _run_code
> exec(code, run_globals)
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/__main__.py",
> line 39, in
> cli.main()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 430, in main
> run()
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/adapter/../../debugpy/launcher/../../debugpy/../debugpy/server/cli.py",
> line 284, in run_file
> runpy.run_path(target, run_name="__main__")
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 321, in run_path
> return _run_module_code(code, init_globals, run_name,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 135, in _run_module_code
> _run_code(code, mod_globals, init_globals,
> File
> "/home/matt/.vscode/extensions/ms-python.python-2023.4.1/pythonFiles/lib/python/debugpy/_vendored/pydevd/_pydevd_bundle/pydevd_runpy.py",
> line 124, in _run_code
> exec(code, run_globals)
> File "/home/matt/Projects/tada/thermo/repro.py", line 6, in
> g.V(2**31 + 1).next()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 117, in next
> return self.__next__()
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 48, in __next__
> self.traversal_strategies.apply_strategies(self)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/process/traversal.py",
> line 684, in apply_strategies
> traversal_strategy.apply(traversal)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/remote_connection.py",
> line 78, in apply
> remote_traversal = self.remote_connection.submit(traversal.bytecode)
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/driver_remote_connection.py",
> line 104, in submit
> result_set = self._client.submit(bytecode,
> request_options=self._extract_request_options(bytecode))
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/client.py",
> line 150, in submit
> return self.submit_async(message, bindings=bindings,
> request_options=request_options).result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 458, in result
> return self.__get_result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in
> __get_result
> raise self._exception
> File
> "/home/matt/Projects/tada/thermo/.venv/lib/python3.10/site-packages/gremlin_python/driver/connection.py",
> line 73, in cb
> f.result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 451, in result
> return self.__get_result()
> File "/usr/lib/python3.10/concurrent/futures/_base.py", line 403, in
> __get_result
[jira] [Created] (TINKERPOP-2937) Throw an error when trying to use a closed connection
Valentyn Kahamlyk created TINKERPOP-2937:
Summary: 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: Improvement
Components: python
Affects Versions: 3.5.5
Reporter: Valentyn Kahamlyk
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] [Created] (TINKERPOP-2936) Optimization for session and transaction handling for GLV's
Valentyn Kahamlyk created TINKERPOP-2936: Summary: Optimization for session and transaction handling for GLV's Key: TINKERPOP-2936 URL: https://issues.apache.org/jira/browse/TINKERPOP-2936 Project: TinkerPop Issue Type: Improvement Components: go, javascript, python Affects Versions: 3.5.5, 3.6.2 Reporter: Valentyn Kahamlyk Now, when creating a new session or transaction, a new WebSocket connection is opened, which is not very efficient in terms of performance and resource consumption. I propose to do as in Java, use single connection pool for all sessions and transactions. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2901) Incorrect result caused by has(key, predicate)
[
https://issues.apache.org/jira/browse/TINKERPOP-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2901.
Resolution: Fixed
> Incorrect result caused by has(key, predicate)
> --
>
> Key: TINKERPOP-2901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2901
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Critical
> Fix For: 3.7.0, 3.6.3
>
>
> Hi! I execute the following gremlin statements:
>
> {code:java}
> (1) g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).count()
> => 6
> (2)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).has("prop4",
> gt(1)).count()
> => 0
> (3)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).not(__.has("prop4",
> gt(1))).count()
> => 4
> # Query Partition => (1) should equals (2) + (3)
> (4)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).values("prop4")
> => {-3.5550649939662193e+18, 1.1868212582852746e+18, NaN}
> (5) g.inject(-3.5550649939662193e+18, 1.1868212582852746e+18,
> Double.NaN).is(gt(1)).count()
> => 1{code}
> I believe there might be an issue with the has(key, predicate) method based
> on the results that I have obtained.
> However, I am having difficulty further isolating the bug. Would you be able
> to help me reproduce the issue and confirm whether there is indeed a bug, or
> if I may have misunderstood the has(key, predicate) method? Thank you.
> The graph is created as follows:
> {code:java}
> g.addV("Vlabel1").property("prop4",
> -2.2940462564994032e+17).property("prop30",
> "1VjYYDjUBPCI5pKd").property("prop2",
> 2.885236496196127e+18).property("prop27",
> -1.283089519858595e+18).property("prop28",
> -177934796716677957).property("prop11",
> Double.POSITIVE_INFINITY).property("prop7", Double.NaN).property("prop13",
> 1582080133).property("prop12", "ZfcpYP42sDhMoli").property("prop26",
> -369822694828473072).property("prop15", false).property("prop24",
> -2035481923).property("prop3", -8.101739153023826e+17).property("prop18",
> -8647655841519618606).property("prop17",
> Double.NEGATIVE_INFINITY).property("prop21", "9WXEq").property("prop5",
> 7015971082047412708).property("prop23", false).property("prop16",
> -2545300721734184124).property("prop8", false).property("prop9",
> Double.NEGATIVE_INFINITY).property("prop19", -1148359097).property("prop10",
> 707520215).property("prop29", 8230830081810437976).property("prop20",
> 3.8750319078997024e+17).property("prop14",
> 4460313502400034603).property("prop22", Double.NaN).property("PersonalId",
> 1)g.addV("Vlabel2").property("prop13", 844274909).property("prop14",
> -1075402369199667167).property("PersonalId",
> 2)g.addV("Vlabel3").property("prop7",
> 1.882109465594965e+18).property("prop15", false).property("prop4",
> -3.5550649939662193e+18).property("prop9",
> Double.POSITIVE_INFINITY).property("prop17",
> Double.NEGATIVE_INFINITY).property("prop24", 1755404150).property("prop21",
> "i4zl5FELCSxw977").property("prop13", 837413089).property("prop27",
> Double.NaN).property("prop12", "qihyjdv4ac").property("prop2",
> Double.NEGATIVE_INFINITY).property("prop22",
> Double.POSITIVE_INFINITY).property("prop11",
> -1.2786380272506816e+18).property("prop20",
> 1.69612491533634e+18).property("prop30",
> "IxJp6GCr5FRvbvpm6ua").property("prop29",
> -7960090835127371110).property("prop25", true).property("prop18",
> 1839549868490228748).property("prop16",
> -5686358023541700304).property("prop5",
> 5956272628376797503).property("prop19", -1735914445).property("prop23",
> true).property("prop1", Double.POSITIVE_INFINITY).property("prop3",
> -2.871901232555182e+16).property("prop26",
> 7437263094806337639).property("prop8", false).property("PersonalId",
> 3)g.addV("Vlabel4").property("prop3",
> 1.5543717370352646e+17).property("prop18",
> -7149746309261129994).property("prop24", -320785419).property("prop2",
> -1.3058283314253888e+18).property("prop1",
> -1.0673961612545854e+17).property("prop10", -601759324).property("prop16",
> -2436094159597901640).property("prop8", false).property("prop30",
> "gtrb5gw").property("prop26", 3672383367334424219).property("prop28",
> 478907755955172).property("prop12", "w6ursX930r2Y7r").property("prop27",
> 6.736691901333204e+17).property("prop6",
> -5129032340661124781).property("prop9",
> Double.POSITIVE_INFINITY).property("prop15", true).property("prop23",
> true).property("prop29", 3775213037193570604).property("prop19",
> 434486748).property("prop13", -1813611800).property("prop22",
> Double.POSITIVE_INFINITY).property("prop5",
> 6634760243334332508).property("prop11", Double.NaN).property("prop7",
>
[jira] [Updated] (TINKERPOP-2901) Incorrect result caused by has(key, predicate)
[
https://issues.apache.org/jira/browse/TINKERPOP-2901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2901:
-
Fix Version/s: 3.7.0
3.6.3
> Incorrect result caused by has(key, predicate)
> --
>
> Key: TINKERPOP-2901
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2901
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Critical
> Fix For: 3.7.0, 3.6.3
>
>
> Hi! I execute the following gremlin statements:
>
> {code:java}
> (1) g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).count()
> => 6
> (2)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).has("prop4",
> gt(1)).count()
> => 0
> (3)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).not(__.has("prop4",
> gt(1))).count()
> => 4
> # Query Partition => (1) should equals (2) + (3)
> (4)
> g.V().where(__.values("PersonalId").is(within(4,8,7,10,9,3))).values("prop4")
> => {-3.5550649939662193e+18, 1.1868212582852746e+18, NaN}
> (5) g.inject(-3.5550649939662193e+18, 1.1868212582852746e+18,
> Double.NaN).is(gt(1)).count()
> => 1{code}
> I believe there might be an issue with the has(key, predicate) method based
> on the results that I have obtained.
> However, I am having difficulty further isolating the bug. Would you be able
> to help me reproduce the issue and confirm whether there is indeed a bug, or
> if I may have misunderstood the has(key, predicate) method? Thank you.
> The graph is created as follows:
> {code:java}
> g.addV("Vlabel1").property("prop4",
> -2.2940462564994032e+17).property("prop30",
> "1VjYYDjUBPCI5pKd").property("prop2",
> 2.885236496196127e+18).property("prop27",
> -1.283089519858595e+18).property("prop28",
> -177934796716677957).property("prop11",
> Double.POSITIVE_INFINITY).property("prop7", Double.NaN).property("prop13",
> 1582080133).property("prop12", "ZfcpYP42sDhMoli").property("prop26",
> -369822694828473072).property("prop15", false).property("prop24",
> -2035481923).property("prop3", -8.101739153023826e+17).property("prop18",
> -8647655841519618606).property("prop17",
> Double.NEGATIVE_INFINITY).property("prop21", "9WXEq").property("prop5",
> 7015971082047412708).property("prop23", false).property("prop16",
> -2545300721734184124).property("prop8", false).property("prop9",
> Double.NEGATIVE_INFINITY).property("prop19", -1148359097).property("prop10",
> 707520215).property("prop29", 8230830081810437976).property("prop20",
> 3.8750319078997024e+17).property("prop14",
> 4460313502400034603).property("prop22", Double.NaN).property("PersonalId",
> 1)g.addV("Vlabel2").property("prop13", 844274909).property("prop14",
> -1075402369199667167).property("PersonalId",
> 2)g.addV("Vlabel3").property("prop7",
> 1.882109465594965e+18).property("prop15", false).property("prop4",
> -3.5550649939662193e+18).property("prop9",
> Double.POSITIVE_INFINITY).property("prop17",
> Double.NEGATIVE_INFINITY).property("prop24", 1755404150).property("prop21",
> "i4zl5FELCSxw977").property("prop13", 837413089).property("prop27",
> Double.NaN).property("prop12", "qihyjdv4ac").property("prop2",
> Double.NEGATIVE_INFINITY).property("prop22",
> Double.POSITIVE_INFINITY).property("prop11",
> -1.2786380272506816e+18).property("prop20",
> 1.69612491533634e+18).property("prop30",
> "IxJp6GCr5FRvbvpm6ua").property("prop29",
> -7960090835127371110).property("prop25", true).property("prop18",
> 1839549868490228748).property("prop16",
> -5686358023541700304).property("prop5",
> 5956272628376797503).property("prop19", -1735914445).property("prop23",
> true).property("prop1", Double.POSITIVE_INFINITY).property("prop3",
> -2.871901232555182e+16).property("prop26",
> 7437263094806337639).property("prop8", false).property("PersonalId",
> 3)g.addV("Vlabel4").property("prop3",
> 1.5543717370352646e+17).property("prop18",
> -7149746309261129994).property("prop24", -320785419).property("prop2",
> -1.3058283314253888e+18).property("prop1",
> -1.0673961612545854e+17).property("prop10", -601759324).property("prop16",
> -2436094159597901640).property("prop8", false).property("prop30",
> "gtrb5gw").property("prop26", 3672383367334424219).property("prop28",
> 478907755955172).property("prop12", "w6ursX930r2Y7r").property("prop27",
> 6.736691901333204e+17).property("prop6",
> -5129032340661124781).property("prop9",
> Double.POSITIVE_INFINITY).property("prop15", true).property("prop23",
> true).property("prop29", 3775213037193570604).property("prop19",
> 434486748).property("prop13", -1813611800).property("prop22",
> Double.POSITIVE_INFINITY).property("prop5",
> 6634760243334332508).property("prop11",
[jira] [Closed] (TINKERPOP-2934) Optimize ObjectWritable for displaying content of Java Collection or Map to reduce OOM
[ https://issues.apache.org/jira/browse/TINKERPOP-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk closed TINKERPOP-2934. Resolution: Fixed > Optimize ObjectWritable for displaying content of Java Collection or Map to > reduce OOM > -- > > Key: TINKERPOP-2934 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2934 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.6.2 >Reporter: Redriver >Priority: Major > Fix For: 3.7.0, 3.6.3, 3.5.6 > > Attachments: image-2023-04-27-15-08-10-874.png > > > OLAP query easily triggers OOM, I found a possible reason is > [https://github.com/apache/tinkerpop/blob/master/hadoop-gremlin/src/main/java/org/apache/tinkerpop/gremlin/hadoop/structure/io/ObjectWritable.java#L72] > dump a huge string output. See what I captureed from SparkUI. In fact, that > toString() does not make much sense for OLAP processing except for displaying > in UI. Furthermore, those too long string is not readable for people. So, > ideally the toString() for Map or Collection should be optimized to be java > class + size(). Then the OOM will disappear. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2934) Optimize ObjectWritable for displaying content of Java Collection or Map to reduce OOM
[ https://issues.apache.org/jira/browse/TINKERPOP-2934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Valentyn Kahamlyk updated TINKERPOP-2934: - Fix Version/s: 3.7.0 3.6.3 3.5.6 > Optimize ObjectWritable for displaying content of Java Collection or Map to > reduce OOM > -- > > Key: TINKERPOP-2934 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2934 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.6.2 >Reporter: Redriver >Priority: Major > Fix For: 3.7.0, 3.6.3, 3.5.6 > > Attachments: image-2023-04-27-15-08-10-874.png > > > OLAP query easily triggers OOM, I found a possible reason is > [https://github.com/apache/tinkerpop/blob/master/hadoop-gremlin/src/main/java/org/apache/tinkerpop/gremlin/hadoop/structure/io/ObjectWritable.java#L72] > dump a huge string output. See what I captureed from SparkUI. In fact, that > toString() does not make much sense for OLAP processing except for displaying > in UI. Furthermore, those too long string is not readable for people. So, > ideally the toString() for Map or Collection should be optimized to be java > class + size(). Then the OOM will disappear. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2820) gremlin-python _close_session race condition/FD leak
[
https://issues.apache.org/jira/browse/TINKERPOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2820.
Resolution: Fixed
> gremlin-python _close_session race condition/FD leak
>
>
> Key: TINKERPOP-2820
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2820
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
>Reporter: Alex Hamilton
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> There is a race condition in gremlin-python when closing session-based
> connections that results in leaking file descriptors for event loops -
> eventually leading to an `OSError [Errno 24] too many open files` error after
> enough transactions occur.
> The problem stems from a race condition when closing session based
> connections that causes the event loop opened for the session's connection to
> be left open.
> The problem is completely contained in these two methods from
> `gremlin_python.driver.client.py`
> ```py
> def close(self):
> # prevent the Client from being closed more than once. it raises errors
> if new jobby jobs
> # get submitted to the executor when it is shutdown
> if self._closed:
> return
> if self._session_enabled:
> self._close_session() # 1. (see below)
> log.info("Closing Client with url '%s'", self._url)
> while not self._pool.empty(): # 3. (see below)
> conn = self._pool.get(True)
> conn.close()
> self._executor.shutdown()
> self._closed = True
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> return conn.write(message).result() # 2. (see below)
> ```
> 1. `_close_session()` called
> 2. `.result()` waits for the _write_ to finish, but does *not* wait for the
> _read_ to finish. `conn` does not get put back into `self._pool` until AFTER
> the read finishes (`gremlin_python.driver.connection.Connection._receive()`).
> However, this method returns early and goes to 3.
> 3. this while loop is not entered to close out the connections. This leaves
> the conn's event loop running, never to be closed.
> I was able to solve this by modifying `_close_session` as follows:
> ```py
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> try:
> write_result_set = conn.write(message).result()
> return write_result_set.all().result() # wait for _receive() to finish
> except protocol.GremlinServerError:
> pass
> ```
> I'm not sure if this is the correct solution, but wanted to point out the bug.
> In the meantime however, I wrote a context manager to handle this cleanup for
> me
> ```py
> @contextlib.contextmanager
> def transaction():
> tx = g.tx()
> gtx = tx.begin()
> try:
> yield tx, gtx
> tx.commit()
> except Exception as e:
> tx.rollback()
> finally:
> while not tx._session_based_connection._client._pool.empty():
> conn = tx._session_based_connection._client._pool.get(True)
> conn.close()
> logger.info("Closed abandoned session connection")
> with transaction() as (tx, gtx):
> foo = gtx.some_traversal().to_list()
> # do something with foo
> gtx.some_other_traversal().iterate()
> ```
> Cheers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2820) gremlin-python _close_session race condition/FD leak
[
https://issues.apache.org/jira/browse/TINKERPOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2820:
-
Fix Version/s: 3.7.0
3.6.3
3.5.6
> gremlin-python _close_session race condition/FD leak
>
>
> Key: TINKERPOP-2820
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2820
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
>Reporter: Alex Hamilton
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> There is a race condition in gremlin-python when closing session-based
> connections that results in leaking file descriptors for event loops -
> eventually leading to an `OSError [Errno 24] too many open files` error after
> enough transactions occur.
> The problem stems from a race condition when closing session based
> connections that causes the event loop opened for the session's connection to
> be left open.
> The problem is completely contained in these two methods from
> `gremlin_python.driver.client.py`
> ```py
> def close(self):
> # prevent the Client from being closed more than once. it raises errors
> if new jobby jobs
> # get submitted to the executor when it is shutdown
> if self._closed:
> return
> if self._session_enabled:
> self._close_session() # 1. (see below)
> log.info("Closing Client with url '%s'", self._url)
> while not self._pool.empty(): # 3. (see below)
> conn = self._pool.get(True)
> conn.close()
> self._executor.shutdown()
> self._closed = True
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> return conn.write(message).result() # 2. (see below)
> ```
> 1. `_close_session()` called
> 2. `.result()` waits for the _write_ to finish, but does *not* wait for the
> _read_ to finish. `conn` does not get put back into `self._pool` until AFTER
> the read finishes (`gremlin_python.driver.connection.Connection._receive()`).
> However, this method returns early and goes to 3.
> 3. this while loop is not entered to close out the connections. This leaves
> the conn's event loop running, never to be closed.
> I was able to solve this by modifying `_close_session` as follows:
> ```py
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> try:
> write_result_set = conn.write(message).result()
> return write_result_set.all().result() # wait for _receive() to finish
> except protocol.GremlinServerError:
> pass
> ```
> I'm not sure if this is the correct solution, but wanted to point out the bug.
> In the meantime however, I wrote a context manager to handle this cleanup for
> me
> ```py
> @contextlib.contextmanager
> def transaction():
> tx = g.tx()
> gtx = tx.begin()
> try:
> yield tx, gtx
> tx.commit()
> except Exception as e:
> tx.rollback()
> finally:
> while not tx._session_based_connection._client._pool.empty():
> conn = tx._session_based_connection._client._pool.get(True)
> conn.close()
> logger.info("Closed abandoned session connection")
> with transaction() as (tx, gtx):
> foo = gtx.some_traversal().to_list()
> # do something with foo
> gtx.some_other_traversal().iterate()
> ```
> Cheers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2820) gremlin-python _close_session race condition/FD leak
[
https://issues.apache.org/jira/browse/TINKERPOP-2820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2820:
Assignee: Valentyn Kahamlyk
> gremlin-python _close_session race condition/FD leak
>
>
> Key: TINKERPOP-2820
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2820
> Project: TinkerPop
> Issue Type: Bug
> Components: python
>Affects Versions: 3.6.1
>Reporter: Alex Hamilton
>Assignee: Valentyn Kahamlyk
>Priority: Critical
>
> There is a race condition in gremlin-python when closing session-based
> connections that results in leaking file descriptors for event loops -
> eventually leading to an `OSError [Errno 24] too many open files` error after
> enough transactions occur.
> The problem stems from a race condition when closing session based
> connections that causes the event loop opened for the session's connection to
> be left open.
> The problem is completely contained in these two methods from
> `gremlin_python.driver.client.py`
> ```py
> def close(self):
> # prevent the Client from being closed more than once. it raises errors
> if new jobby jobs
> # get submitted to the executor when it is shutdown
> if self._closed:
> return
> if self._session_enabled:
> self._close_session() # 1. (see below)
> log.info("Closing Client with url '%s'", self._url)
> while not self._pool.empty(): # 3. (see below)
> conn = self._pool.get(True)
> conn.close()
> self._executor.shutdown()
> self._closed = True
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> return conn.write(message).result() # 2. (see below)
> ```
> 1. `_close_session()` called
> 2. `.result()` waits for the _write_ to finish, but does *not* wait for the
> _read_ to finish. `conn` does not get put back into `self._pool` until AFTER
> the read finishes (`gremlin_python.driver.connection.Connection._receive()`).
> However, this method returns early and goes to 3.
> 3. this while loop is not entered to close out the connections. This leaves
> the conn's event loop running, never to be closed.
> I was able to solve this by modifying `_close_session` as follows:
> ```py
> def _close_session(self):
> message = request.RequestMessage(
> processor='session', op='close',
> args=\{'session': str(self._session)})
> conn = self._pool.get(True)
> try:
> write_result_set = conn.write(message).result()
> return write_result_set.all().result() # wait for _receive() to finish
> except protocol.GremlinServerError:
> pass
> ```
> I'm not sure if this is the correct solution, but wanted to point out the bug.
> In the meantime however, I wrote a context manager to handle this cleanup for
> me
> ```py
> @contextlib.contextmanager
> def transaction():
> tx = g.tx()
> gtx = tx.begin()
> try:
> yield tx, gtx
> tx.commit()
> except Exception as e:
> tx.rollback()
> finally:
> while not tx._session_based_connection._client._pool.empty():
> conn = tx._session_based_connection._client._pool.get(True)
> conn.close()
> logger.info("Closed abandoned session connection")
> with transaction() as (tx, gtx):
> foo = gtx.some_traversal().to_list()
> # do something with foo
> gtx.some_other_traversal().iterate()
> ```
> Cheers
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2490) RangeGlobalStep touches next traverser when high limit is already hit
[
https://issues.apache.org/jira/browse/TINKERPOP-2490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17715508#comment-17715508
]
Valentyn Kahamlyk commented on TINKERPOP-2490:
--
this behavior is part of `CountStrategy` optimization and it looks correct.
how can you read only 1 vertex to know that there are less than 2 of them?
> RangeGlobalStep touches next traverser when high limit is already hit
> -
>
> Key: TINKERPOP-2490
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2490
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.8
>Reporter: Guo Junshi
>Priority: Major
>
> In FilterStep, the processNextStart() method will first retrieve next
> traverser and then apply filtering logic. But for RangleGlobalStep, if high
> limit is already hit, there will be no need to get next traverser.
> {code:java}
> @Override
> protected Traverser.Admin processNextStart() {
> while (true) {
> final Traverser.Admin traverser = this.starts.next();
> if (this.filter(traverser))
> return traverser;
> }
> }
> {code}
> An example would be limit step: g.V().limit(1). This query will touch 2
> vertices although only 1 vertex will be returned.
> This extra data loading will cause performance defects if DB data loading is
> involved. It is not a functionality bug, but for better performance, we'd
> better check high range limit first before touching next traversal.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2926) Gremlin-Java > An UnsupportedOperationException occurs on calling next() after a merge step with the option step modulator if the element does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2926:
-
Fix Version/s: 3.7.0
3.6.3
> Gremlin-Java > An UnsupportedOperationException occurs on calling next()
> after a merge step with the option step modulator if the element does not
> exist
>
>
> Key: TINKERPOP-2926
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2926
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.2
>Reporter: Andrew Kirk
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
> Fix For: 3.7.0, 3.6.3
>
> Attachments: MergeTestApp.java
>
>
> Using Gremlin-Java, when the option step modulator is used in combination
> with a merge step, an `UnsupportedOperationException` is thrown upon calling
> `next()` if the specified element does not already exist.
> Using an example from the docs, the following construct works fine in the
> console if the element does not already exist:
> {code:groovy}
> gremlin> g.mergeV([(T.id):300]).
> option(Merge.onCreate,[(T.label):'Dog', name:'Toby', age:10]).
> option(Merge.onMatch,[age:11])
> {code}
> But, if we try to do the same thing in Java, we'll get an exception:
> {code:java}
> g.mergeV(Map.of(T.id, 300))
> .option(
> Merge.onCreate,
> Map.of(
> T.label, "Dog",
> "name", "Toby",
> "age", 10
> )
> )
> .option(
> Merge.onMatch,
> Map.of("age", 11)
> )
> .next();
> {code}
> Exception:
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException
> at
> java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
> at
> java.base/java.util.ImmutableCollections$AbstractImmutableMap.putAll(ImmutableCollections.java:1073)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.onCreateMap(MergeVertexStep.java:205)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.flatMap(MergeVertexStep.java:168)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.FlatMapStep.processNextStart(FlatMapStep.java:49)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeStep.processNextStart(MergeStep.java:165)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:135)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:40)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:249)
> at
> io.integralla.tinkerpop.poc.MergeWithOption.main(MergeWithOption.java:44)
> {noformat}
> If the element is first added (via an add or merge step), the merge with
> option works as expected.
> A full example is provided in the attached MergeTestApp.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2890) Avoid exceptions on local scope based steps where possible
[
https://issues.apache.org/jira/browse/TINKERPOP-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2890:
-
Fix Version/s: 3.7.0
3.6.3
3.5.6
> Avoid exceptions on local scope based steps where possible
> --
>
> Key: TINKERPOP-2890
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2890
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> If you {{g.inject([1,2], 1])dedup(local)}} you get an casting error because
> "1" is not an {{Iterable}} and {{local}} only works with that type. Would be
> better if a {{dedup()}} of a non-iterable just returned the object itself.
> Consider other steps that use {{local}} and make similar improvements there
> for consistency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2926) Gremlin-Java > An UnsupportedOperationException occurs on calling next() after a merge step with the option step modulator if the element does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2926.
Resolution: Fixed
> Gremlin-Java > An UnsupportedOperationException occurs on calling next()
> after a merge step with the option step modulator if the element does not
> exist
>
>
> Key: TINKERPOP-2926
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2926
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.2
>Reporter: Andrew Kirk
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
> Fix For: 3.7.0, 3.6.3
>
> Attachments: MergeTestApp.java
>
>
> Using Gremlin-Java, when the option step modulator is used in combination
> with a merge step, an `UnsupportedOperationException` is thrown upon calling
> `next()` if the specified element does not already exist.
> Using an example from the docs, the following construct works fine in the
> console if the element does not already exist:
> {code:groovy}
> gremlin> g.mergeV([(T.id):300]).
> option(Merge.onCreate,[(T.label):'Dog', name:'Toby', age:10]).
> option(Merge.onMatch,[age:11])
> {code}
> But, if we try to do the same thing in Java, we'll get an exception:
> {code:java}
> g.mergeV(Map.of(T.id, 300))
> .option(
> Merge.onCreate,
> Map.of(
> T.label, "Dog",
> "name", "Toby",
> "age", 10
> )
> )
> .option(
> Merge.onMatch,
> Map.of("age", 11)
> )
> .next();
> {code}
> Exception:
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException
> at
> java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
> at
> java.base/java.util.ImmutableCollections$AbstractImmutableMap.putAll(ImmutableCollections.java:1073)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.onCreateMap(MergeVertexStep.java:205)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.flatMap(MergeVertexStep.java:168)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.FlatMapStep.processNextStart(FlatMapStep.java:49)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeStep.processNextStart(MergeStep.java:165)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:135)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:40)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:249)
> at
> io.integralla.tinkerpop.poc.MergeWithOption.main(MergeWithOption.java:44)
> {noformat}
> If the element is first added (via an add or merge step), the merge with
> option works as expected.
> A full example is provided in the attached MergeTestApp.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2890) Avoid exceptions on local scope based steps where possible
[
https://issues.apache.org/jira/browse/TINKERPOP-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2890.
Resolution: Fixed
> Avoid exceptions on local scope based steps where possible
> --
>
> Key: TINKERPOP-2890
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2890
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.5
>Reporter: Stephen Mallette
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> If you {{g.inject([1,2], 1])dedup(local)}} you get an casting error because
> "1" is not an {{Iterable}} and {{local}} only works with that type. Would be
> better if a {{dedup()}} of a non-iterable just returned the object itself.
> Consider other steps that use {{local}} and make similar improvements there
> for consistency.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (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:comment-tabpanel=17715159#comment-17715159 ] Valentyn Kahamlyk commented on TINKERPOP-2832: -- Default session timeout is 8 hours, most Gremlin Server configurations also use this value. However, when this time is configured with a much lower value, then the following sequence of events is possible: 1. Client starts new session on server 2. Client sets some variables or make some changes in transaction 3. Client looses connection 4. Server removes session as expired 5. Client reconnects and try to continue to work with opened session 6. Server creates new session with same ID Resulting in an inconsistent state and possible data loss in the transaction. Proposed solution for 3.5/3.6: after closing the session, have the server keep its id for some more time and do not allow creating a session with same ID, throw an error when such an attempt is made. The longer term plan is to re-design the entire session logic as part of transaction implementation in TinkerGraph in 3.7 > 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: Critical > > 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] [Assigned] (TINKERPOP-2926) Gremlin-Java > An UnsupportedOperationException occurs on calling next() after a merge step with the option step modulator if the element does not exist
[
https://issues.apache.org/jira/browse/TINKERPOP-2926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reassigned TINKERPOP-2926:
Assignee: Valentyn Kahamlyk
> Gremlin-Java > An UnsupportedOperationException occurs on calling next()
> after a merge step with the option step modulator if the element does not
> exist
>
>
> Key: TINKERPOP-2926
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2926
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.6.2
>Reporter: Andrew Kirk
>Assignee: Valentyn Kahamlyk
>Priority: Blocker
> Attachments: MergeTestApp.java
>
>
> Using Gremlin-Java, when the option step modulator is used in combination
> with a merge step, an `UnsupportedOperationException` is thrown upon calling
> `next()` if the specified element does not already exist.
> Using an example from the docs, the following construct works fine in the
> console if the element does not already exist:
> {code:groovy}
> gremlin> g.mergeV([(T.id):300]).
> option(Merge.onCreate,[(T.label):'Dog', name:'Toby', age:10]).
> option(Merge.onMatch,[age:11])
> {code}
> But, if we try to do the same thing in Java, we'll get an exception:
> {code:java}
> g.mergeV(Map.of(T.id, 300))
> .option(
> Merge.onCreate,
> Map.of(
> T.label, "Dog",
> "name", "Toby",
> "age", 10
> )
> )
> .option(
> Merge.onMatch,
> Map.of("age", 11)
> )
> .next();
> {code}
> Exception:
> {noformat}
> Exception in thread "main" java.lang.UnsupportedOperationException
> at
> java.base/java.util.ImmutableCollections.uoe(ImmutableCollections.java:142)
> at
> java.base/java.util.ImmutableCollections$AbstractImmutableMap.putAll(ImmutableCollections.java:1073)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.onCreateMap(MergeVertexStep.java:205)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeVertexStep.flatMap(MergeVertexStep.java:168)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.FlatMapStep.processNextStart(FlatMapStep.java:49)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.map.MergeStep.processNextStart(MergeStep.java:165)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:135)
> at
> org.apache.tinkerpop.gremlin.process.traversal.step.util.AbstractStep.next(AbstractStep.java:40)
> at
> org.apache.tinkerpop.gremlin.process.traversal.util.DefaultTraversal.next(DefaultTraversal.java:249)
> at
> io.integralla.tinkerpop.poc.MergeWithOption.main(MergeWithOption.java:44)
> {noformat}
> If the element is first added (via an add or merge step), the merge with
> option works as expected.
> A full example is provided in the attached MergeTestApp.java
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2891.
Resolution: Fixed
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reopened TINKERPOP-2891:
--
Assignee: Valentyn Kahamlyk
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Assignee: Valentyn Kahamlyk
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2891.
Resolution: Fixed
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2891:
-
Fix Version/s: 3.7.0
3.6.3
3.5.6
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Critical
> Fix For: 3.7.0, 3.6.3, 3.5.6
>
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk reopened TINKERPOP-2891:
--
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Critical
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2891) Inconsistent behavior when comparing a counted value with a negative value
[
https://issues.apache.org/jira/browse/TINKERPOP-2891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk closed TINKERPOP-2891.
Resolution: Fixed
> Inconsistent behavior when comparing a counted value with a negative value
> --
>
> Key: TINKERPOP-2891
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2891
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Lei Tang
>Priority: Critical
>
> I compare a value that should be greater than or equal to 0 with a negative
> value.
> {code:java}
> gremlin> :> g.V().where(__.in().count().is(eq(-3)))
> Not a legal range: [0, -2]
> gremlin> :> g.V().where(__.in().count().is(eq(-2))){code}
> I find that Tinkergraph throws an exception when comparing negative values
> less than -2, but does nothing when comparing with -2.
> I'm curious why they behave differently.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2904) Forget to throw GremlinTypeErrorException when using is(predicate) to compare NaN
[
https://issues.apache.org/jira/browse/TINKERPOP-2904?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2904:
-
Component/s: process
> Forget to throw GremlinTypeErrorException when using is(predicate) to compare
> NaN
> --
>
> Key: TINKERPOP-2904
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2904
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.5.5
>Reporter: Miracy Cavendish
>Priority: Major
>
> By the design of Gremlin, an exception should be thrown when compared with
> NaN.
> However, I found that when using ```is(predicate)``` to compare, the
> exception is always swallowed, and this issue occurs on all GDBs support
> Gremlin, such as "g.inject(Double.NaN).is(gt(3))"
> {code:java}
> public static final GremlinValueComparator COMPARABILITY = new
> GremlinValueComparator() {
> /**
> * Compare two Gremlin value objects per the Comparability semantics.
> Throws type errors for NaN comparison
> * and for cross-type comparison (including nulltype).
> *
> * Use this method for P.lt/lte/gt/gte.
> */
> @Override
> public int compare(final Object f, final Object s) {
> // For Compare, NaN always produces ERROR
> if (eitherAreNaN(f, s))
> throwTypeError();
> // For Compare we do not cross type boundaries, including null
> if (!comparable(f, s))
> throwTypeError();
> // comparable(f, s) assures that type(f) == type(s)
> final Type type = Type.type(f);
> return comparator(type).compare(f, s);
> }
> ... {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2906) Query using coalesce adding the same vertex twice
[
https://issues.apache.org/jira/browse/TINKERPOP-2906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Valentyn Kahamlyk updated TINKERPOP-2906:
-
Component/s: process
> Query using coalesce adding the same vertex twice
> -
>
> Key: TINKERPOP-2906
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2906
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.0, 3.6.2
>Reporter: Kelvin Lawrence
>Priority: Major
>
> While looking into a question on Stack Overflow about selectively adding a
> vertex based on a set of values in a list, I think I may have run into an odd
> issue. Note that this can also be solved using mergeV, but that
> notwithstanding, the behavior below seems odd. It can be reproduced just
> using TinkerGraph and the Gremlin Console. Everything works as expected until
> the RHS of the coalesce() step is an addV() step.
>
> {code:java}
> gremlin> g.addV('Person').property('name','Sam')
> ==>v[16]gremlin> g
> ==>graphtraversalsource[tinkergraph[vertices:1 edges:0], standard]gremlin>
> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),constant(1))
> ==>v[16]
> ==>1
> ==>1gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),select('find'))
> ==>v[16]
> ==>Peter
> ==>Frankgremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),addV('Person').property('name',select('find'))
> ..7> )
> ==>v[16]
> ==>v[18]
> ==>v[20]
> ==>v[22]gremlin> g.V().valueMap(true)
> ==>[id:16,label:Person,name:[Sam]]
> ==>[id:18,label:Person,name:[Peter]]
> ==>[id:20,label:Person,name:[Frank]]
> ==>[id:22,label:Person,name:[Frank]]
>
> gremlin> g.V().drop()gremlin> g.addV('Person').property('name','Sam')
> ==>v[24]gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').
> ..2> V().as('p').
> ..3> coalesce(
> ..4> where(eq('p')).
> ..5> by(select('find')).
> ..6> by('name'),
> ..7> addV('Person').property('name',select('find'))).profile()
> ==>Traversal Metrics
> Step Count Traversers Time (ms) % Dur
> =
> InjectStep([[Sam, Peter, Frank]]) 1 1 0.043 4.19
> UnfoldStep@[find] 3 3 0.083 8.00
> TinkerGraphStep(vertex,[])@[p] 4 4 0.155 14.91
> CoalesceStep([[WherePredicateStep(null,eq(p),[[... 4 4 0.761 72.89
> WherePredicateStep(null,eq(p),[[SelectOneStep... 1 1 0.181
> SelectOneStep(last,find,null) 4 4 0.057
> AddVertexStep({name=[[SelectOneStep(last,find... 3 3 0.246
> SelectOneStep(last,find,null) 3 3 0.025
> >TOTAL - - 1.044 -
> gremlin> g.inject(['Sam','Peter','Frank']).
> ..1> unfold().as('find').V().profile()
> ==>Traversal Metrics
> Step Count Traversers Time (ms) % Dur
> =
> InjectStep([[Sam, Peter, Frank]]) 1 1 0.028 8.93
> UnfoldStep@[find] 3 3 0.043 13.97
> TinkerGraphStep(vertex,[]) 3 3 0.241 77.10
> >TOTAL - - 0.313 -
> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
