[jira] [Commented] (TINKERPOP-2423) hashCode collision for steps with different attributes
[
https://issues.apache.org/jira/browse/TINKERPOP-2423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17769699#comment-17769699
]
ASF GitHub Bot commented on TINKERPOP-2423:
---
xiazcy commented on PR #2254:
URL: https://github.com/apache/tinkerpop/pull/2254#issuecomment-1737734349
VOTE +1
> hashCode collision for steps with different attributes
> --
>
> Key: TINKERPOP-2423
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2423
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.8
>Reporter: Saikiran Boga
>Priority: Major
>
> The {{hashCode computation}} for PropertiesStep collides for multiple steps
> when there are repeating keys. For example {{.properties()}} and
> {{.properties("a","a")}}, {{.properties("a")}} and
> .{{properties("a","b","b")}} have the same hash code because of xor of just
> properties here
> [https://github.com/apache/tinkerpop/blob/cff4c161615f2b50bda27b6ba523c7f52b833532/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/map/PropertiesStep.java#L80-L87].
> Basically, the even keys cancel out the xor computation.
>
> The same is also true for {{AbstractStep.hashCode}} which takes xor of labels.
> {{GraphStep}} does the same thing using ids. so {{g.V("1", "1")}} and
> {{g.V()}} would collide during comparison.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [DISCUSS] Proposal to add possibility to get current server time from traversal.
I much prefer having datetime() with no parameters return the current server date/time. This also keeps the function similar in nature to other query languages (e.g. Cypher). I have had several Gremlin users tell me they were surprised when it did not already behave that way wen they tried it as it seemed "obvious to them" that that is how it would work. Cheers, Kelvin On Tuesday, September 26, 2023 at 07:33:57 PM CDT, Valentyn Kahamlyk wrote: Hi all, Currently, when using a gremlin, there is no way to use the current server time in requests. This can be convenient for storing the creation or update date of elements. Also may be useful when examining query performance. I propose adding this feature. There are some ways to implement it 1. Add a new step `currentDateTime()` which will return the current UTC time. pros: compatible with both bytecode and gremlin cons: one more step 2. Extend `inject` step to accept some kind of tokens, for example `inject(DT.now)` or `inject(DT.utcnow)` pros: can be reused existing step cons: not feel like gremlin 3. Extend `datetime()` function to return current time without arg. pros: clean and easy to implement cons: not compatible with bytecode, what I consider as a blocker I plan to implement option 1 if there are no objections. What do you think? Regards, Valentyn
[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
]
Yang Xia updated TINKERPOP-2996:
Issue Type: Improvement (was: Task)
> 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: Improvement
> Components: go
>Affects Versions: 3.7.0, 3.5.7, 3.6.5
>Reporter: Yang Xia
>Priority: Major
>
> 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
]
Yang Xia updated TINKERPOP-2996:
Priority: Critical (was: Major)
> 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
>
> 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
]
Yang Xia updated TINKERPOP-2996:
Issue Type: Bug (was: Improvement)
> 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: Major
>
> 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-2995) Create Sample Applications in each GLV
[ https://issues.apache.org/jira/browse/TINKERPOP-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2995: Affects Version/s: 3.5.7 > Create Sample Applications in each GLV > -- > > Key: TINKERPOP-2995 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2995 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet, go, javascript, python >Affects Versions: 3.5.7 >Reporter: Yang Xia >Priority: Major > > It would be great to have working example applications for each GLV, with > basic traversal examples and common connection settings. > Currently we have an `example.py` for python, but it is very minimal. There > is also an `example.go` for golang, but that appears to be outdated. As far > as I know, dotnet only has templates and javascript doesn't have any examples > at all. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel
]
Yang Xia updated TINKERPOP-2990:
Priority: Critical (was: Minor)
> 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] [Updated] (TINKERPOP-2988) Serialization error throws an Invalid OpProcessor exception when using stream() API
[
https://issues.apache.org/jira/browse/TINKERPOP-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2988:
Component/s: server
> Serialization error throws an Invalid OpProcessor exception when using
> stream() API
> ---
>
> Key: TINKERPOP-2988
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2988
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.7.0
>Reporter: Taylor Riggan
>Priority: Minor
>
> The following throws an
> {code:java}
> Invalid OpProcessor requested [null] (499){code}
> exception. The cause is due to an invalid RequestId (an non-conformant UUID
> is being used):
> {code:java}
> resp = client.stream ("g.V()", {}, { batchSize: 1, requestId: 'foo',
> userAgent: 'bar', evaluationTimeout: 5000 });{code}
>
> The error was diagnosed using Gremlin Server 3.7.0 and seeing the following
> in the server logs:
>
> {code:java}
> [WARN] o.a.t.g.s.h.WsGremlinBinaryRequestDecoder - Serialization error while
> decoding request
> org.apache.tinkerpop.gremlin.driver.ser.SerializationException:
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not
> deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.databind.exc.InvalidFormatException:
> Cannot deserialize value of type `java.util.UUID` from String "foo": UUID has
> to be represented by standard 36-char representation
> at [Source: (byte[])"{"requestId":{{{}
> {"@type":"g:UUID","@value":"foo"}
> {}}},"op":"eval","processor":"","args":{"gremlin":"g.V()","aliases":{{{}
> {"g":"g"}
> {}}},"batchSize":1,"userAgent":"bar","evaluationTimeout":5000,"bindings":{},"language":"gremlin-groovy","accept":"application/vnd.gremlin-v3.0+json"";
> line: 1, column: 41]{}}}
> at [Source: (byte[])"{"requestId":{{{}
> {"@type":"g:UUID","@value":"foo"}
> {}}},"op":"eval","processor":"","args":{"gremlin":"g.V()","aliases":{{{}
> {"g":"g"}
> {}}},"batchSize":1,"userAgent":"bar","evaluationTimeout":5000,"bindings":{},"language":"gremlin-groovy","accept":"application/vnd.gremlin-v3.0+json"";
> line: 1, column: 41] (through reference chain:
> java.util.LinkedHashMap["requestId"]){}}}
> at
> org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0.deserializeRequest(AbstractGraphSONMessageSerializerV2d0.java:124)
> at
> org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder.decode(WsGremlinBinaryRequestDecoder.java:77)
>
> {code}
>
> A better client side error message is needed in order to provide the user
> with guidance on how to fix the issue. `Invalid OpProcessor` is too
> ambiguous.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2988) Serialization error throws an Invalid OpProcessor exception when using stream() API
[
https://issues.apache.org/jira/browse/TINKERPOP-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2988:
Priority: Critical (was: Minor)
> Serialization error throws an Invalid OpProcessor exception when using
> stream() API
> ---
>
> Key: TINKERPOP-2988
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2988
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.7.0
>Reporter: Taylor Riggan
>Priority: Critical
>
> The following throws an
> {code:java}
> Invalid OpProcessor requested [null] (499){code}
> exception. The cause is due to an invalid RequestId (an non-conformant UUID
> is being used):
> {code:java}
> resp = client.stream ("g.V()", {}, { batchSize: 1, requestId: 'foo',
> userAgent: 'bar', evaluationTimeout: 5000 });{code}
>
> The error was diagnosed using Gremlin Server 3.7.0 and seeing the following
> in the server logs:
>
> {code:java}
> [WARN] o.a.t.g.s.h.WsGremlinBinaryRequestDecoder - Serialization error while
> decoding request
> org.apache.tinkerpop.gremlin.driver.ser.SerializationException:
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not
> deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.databind.exc.InvalidFormatException:
> Cannot deserialize value of type `java.util.UUID` from String "foo": UUID has
> to be represented by standard 36-char representation
> at [Source: (byte[])"{"requestId":{{{}
> {"@type":"g:UUID","@value":"foo"}
> {}}},"op":"eval","processor":"","args":{"gremlin":"g.V()","aliases":{{{}
> {"g":"g"}
> {}}},"batchSize":1,"userAgent":"bar","evaluationTimeout":5000,"bindings":{},"language":"gremlin-groovy","accept":"application/vnd.gremlin-v3.0+json"";
> line: 1, column: 41]{}}}
> at [Source: (byte[])"{"requestId":{{{}
> {"@type":"g:UUID","@value":"foo"}
> {}}},"op":"eval","processor":"","args":{"gremlin":"g.V()","aliases":{{{}
> {"g":"g"}
> {}}},"batchSize":1,"userAgent":"bar","evaluationTimeout":5000,"bindings":{},"language":"gremlin-groovy","accept":"application/vnd.gremlin-v3.0+json"";
> line: 1, column: 41] (through reference chain:
> java.util.LinkedHashMap["requestId"]){}}}
> at
> org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0.deserializeRequest(AbstractGraphSONMessageSerializerV2d0.java:124)
> at
> org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder.decode(WsGremlinBinaryRequestDecoder.java:77)
>
> {code}
>
> A better client side error message is needed in order to provide the user
> with guidance on how to fix the issue. `Invalid OpProcessor` is too
> ambiguous.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2988) Serialization error throws an Invalid OpProcessor exception when using stream() API
[
https://issues.apache.org/jira/browse/TINKERPOP-2988?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17769756#comment-17769756
]
Yang Xia commented on TINKERPOP-2988:
-
Potentially add a client-side check for proper request ID to avoid the error.
> Serialization error throws an Invalid OpProcessor exception when using
> stream() API
> ---
>
> Key: TINKERPOP-2988
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2988
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.7.0
>Reporter: Taylor Riggan
>Priority: Minor
>
> The following throws an
> {code:java}
> Invalid OpProcessor requested [null] (499){code}
> exception. The cause is due to an invalid RequestId (an non-conformant UUID
> is being used):
> {code:java}
> resp = client.stream ("g.V()", {}, { batchSize: 1, requestId: 'foo',
> userAgent: 'bar', evaluationTimeout: 5000 });{code}
>
> The error was diagnosed using Gremlin Server 3.7.0 and seeing the following
> in the server logs:
>
> {code:java}
> [WARN] o.a.t.g.s.h.WsGremlinBinaryRequestDecoder - Serialization error while
> decoding request
> org.apache.tinkerpop.gremlin.driver.ser.SerializationException:
> org.apache.tinkerpop.shaded.jackson.databind.JsonMappingException: Could not
> deserialize the JSON value as required. Nested exception:
> org.apache.tinkerpop.shaded.jackson.databind.exc.InvalidFormatException:
> Cannot deserialize value of type `java.util.UUID` from String "foo": UUID has
> to be represented by standard 36-char representation
> at [Source: (byte[])"{"requestId":{{{}
> {"@type":"g:UUID","@value":"foo"}
> {}}},"op":"eval","processor":"","args":{"gremlin":"g.V()","aliases":{{{}
> {"g":"g"}
> {}}},"batchSize":1,"userAgent":"bar","evaluationTimeout":5000,"bindings":{},"language":"gremlin-groovy","accept":"application/vnd.gremlin-v3.0+json"";
> line: 1, column: 41]{}}}
> at [Source: (byte[])"{"requestId":{{{}
> {"@type":"g:UUID","@value":"foo"}
> {}}},"op":"eval","processor":"","args":{"gremlin":"g.V()","aliases":{{{}
> {"g":"g"}
> {}}},"batchSize":1,"userAgent":"bar","evaluationTimeout":5000,"bindings":{},"language":"gremlin-groovy","accept":"application/vnd.gremlin-v3.0+json"";
> line: 1, column: 41] (through reference chain:
> java.util.LinkedHashMap["requestId"]){}}}
> at
> org.apache.tinkerpop.gremlin.driver.ser.AbstractGraphSONMessageSerializerV2d0.deserializeRequest(AbstractGraphSONMessageSerializerV2d0.java:124)
> at
> org.apache.tinkerpop.gremlin.server.handler.WsGremlinBinaryRequestDecoder.decode(WsGremlinBinaryRequestDecoder.java:77)
>
> {code}
>
> A better client side error message is needed in order to provide the user
> with guidance on how to fix the issue. `Invalid OpProcessor` is too
> ambiguous.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2971) having order() before fold() omits an empty list in GroupStep's value traversal
[
https://issues.apache.org/jira/browse/TINKERPOP-2971?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2971:
Priority: Critical (was: Major)
> having order() before fold() omits an empty list in GroupStep's value
> traversal
> ---
>
> Key: TINKERPOP-2971
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2971
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.6.4
>Reporter: Norio Akagi
>Priority: Critical
>
> Using the modern graph,
> {code:java}
> gremlin> g.V().group().by().by(out().fold())
> ==>[v[1]:[v[3],v[2],v[4]],v[2]:[],v[3]:[],v[4]:[v[5],v[3]],v[5]:[],v[6]:[v[3]]]{code}
> {{out().fold()}} produces an empty list when there is no solution for
> {{out()}} in a value traversal of GroupStep. However if I put {{order()}}
> those empty lists are gone.
> {code:java}
> gremlin> g.V().group().by().by(out().order().fold())
> ==>[v[1]:[v[2],v[3],v[4]],v[4]:[v[3],v[5]],v[6]:[v[3]]]{code}
> I think this is not an expected behavior.
> I don't see the similar effect in by() itself
> {code:java}
> gremlin> g.V().as("a").select("a").by(out().fold())
> ==>[v[3],v[2],v[4]]
> ==>[]
> ==>[]
> ==>[v[5],v[3]]
> ==>[]
> ==>[v[3]]{code}
> {code:java}
> gremlin> g.V().as("a").select("a").by(out().order().fold())
> ==>[v[2],v[3],v[4]]
> ==>[]
> ==>[]
> ==>[v[3],v[5]]
> ==>[]
> ==>[v[3]]{code}
> So likely this is GroupStep specific issue. We need to investigate how this
> occurs and fix if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2970) Always correctly close CloseableIterator
[ https://issues.apache.org/jira/browse/TINKERPOP-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2970. --- Resolution: Not A Problem > 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.5.6, 3.6.4 >Reporter: Valentyn Kahamlyk >Priority: Major > > 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-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 ] Yang Xia updated TINKERPOP-2962: Priority: Critical (was: Major) > 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 >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] [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 ] Yang Xia updated TINKERPOP-2964: Priority: Critical (was: Minor) > 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 >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] [Closed] (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:all-tabpanel
]
Yang Xia closed TINKERPOP-2943.
---
Resolution: Duplicate
The specific fix is to use `long` casting in python.
We will continue the discussion around auto-casting in TINKERPOP-2363.
> 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] [Closed] (TINKERPOP-2916) Documentation of the TinkerPop standard for providers
[
https://issues.apache.org/jira/browse/TINKERPOP-2916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2916.
---
Resolution: Not A Problem
Closing as we are currently populating the provider docs
[https://tinkerpop.apache.org/docs/current/dev/provider/#gremlin-semantics]
> Documentation of the TinkerPop standard for providers
> -
>
> Key: TINKERPOP-2916
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2916
> Project: TinkerPop
> Issue Type: Improvement
> Components: language
>Affects Versions: 3.6.2
>Reporter: Martin Häusler
>Priority: Major
>
> As a TinkerPop graph developer, I am often faced with the "internals" of
> TinkerPop (classes such as {{TraversalRing}} and step classes such as
> {{CollectingBarrierStep}} which do not appear in the user-level
> documentation) and I have to do quite a lot of code reading to understand the
> concepts.
> It would be super helpful to have (at least) class level documentation on how
> the internal concepts work. Method level documentation would also be nice;
> for example I only recently fully understood how the {{starts}} field of a
> traversal really works.
> Alternatively / additionally, a documentation page for TinkerPop providers
> which explains the non-user-facing (internal) aspects would be nice to have.
> I know about this page:
> https://tinkerpop.apache.org/docs/current/dev/provider/
> ... and it's good, but it again skips on many internals (for example, it
> should explain that there are so many different implementations of the
> Traverser interface because each step has requirements and the requirements
> of the traversal guide the selection of the traverser class, which have
> varying capabilities). I've been piecing together this knowledge myself over
> time, but that's not only tedious, but also somewhat dangerous because I may
> have got it wrong, or maybe I'm missing some key information. In other words,
> I feel like we need an RFC-style "standard" which transcends the code itself.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (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
]
Yang Xia updated TINKERPOP-2913:
Priority: Critical (was: Minor)
> 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
>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] [Updated] (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
]
Yang Xia updated TINKERPOP-2879:
Priority: Critical (was: Major)
> 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",
> 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",
> true).property("prop28", "QYSjGFWbiy8").property("prop26",
> 1.77992
[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
]
Yang Xia updated TINKERPOP-2877:
Priority: Critical (was: Major)
> 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
>Priority: Critical
>
> {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",
> Double.NEGATIVE_INFINITY).property("prop22", Double.NaN).property("prop14",
> Double.NaN).
[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
]
Yang Xia updated TINKERPOP-2877:
Priority: Blocker (was: Critical)
> 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
>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",
> Double.NEGATIVE_INFINITY).property("prop22", Double.NaN).property("prop14",
> Double.NaN)
[jira] [Updated] (TINKERPOP-2848) Deserialization of integer based datatypes lose the type definition
[ https://issues.apache.org/jira/browse/TINKERPOP-2848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2848: Description: As proposed by this PR [[https://github.com/apache/tinkerpop/pull/1848,|https://github.com/apache/tinkerpop/pull/1848] currently in python, deserializing of integer based datatypes don't preserve the type definition from server. Some discussion may be needed around the impact of updating this deserialization. was: As proposed by this PR [https://github.com/apache/tinkerpop/pull/1848,] currently in python, deserializing of integer based datatypes don't preserve the type definition from server. Some discussion may be needed around the impact of updating this deserialization. > Deserialization of integer based datatypes lose the type definition > --- > > Key: TINKERPOP-2848 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2848 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.5.4 >Reporter: Yang Xia >Priority: Minor > > As proposed by this PR > [[https://github.com/apache/tinkerpop/pull/1848,|https://github.com/apache/tinkerpop/pull/1848] > currently in python, deserializing of integer based datatypes don't preserve > the type definition from server. > Some discussion may be needed around the impact of updating this > deserialization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2830) Handle User-Agent from HTTP Requests to server
[ https://issues.apache.org/jira/browse/TINKERPOP-2830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2830: Priority: Critical (was: Minor) > Handle User-Agent from HTTP Requests to server > -- > > Key: TINKERPOP-2830 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2830 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.5.4 >Reporter: Cole Greer >Priority: Critical > > Changes are being introduced in > [2480|https://issues.apache.org/jira/browse/TINKERPOP-2480] which add a user > agent which is sent as a request header during web socket handshakes. > Originally 2480 was planned to also include the server accepting user agents > from http requests but this has now fallen outside of the scope. This ticket > is to complete the user agent feature by adding the ability for the server to > accept user agents in http requests in addition to web sockets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2823) A drop() after a union() does not drop everything found
[
https://issues.apache.org/jira/browse/TINKERPOP-2823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2823:
Priority: Critical (was: Major)
> A drop() after a union() does not drop everything found
> ---
>
> Key: TINKERPOP-2823
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2823
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.1
> Environment: Gremlin Console, TinkerPop 3.6
>Reporter: Kelvin Lawrence
>Priority: Critical
>
> This may be related to https://issues.apache.org/jira/browse/TINKERPOP-2627,
> but on the surface appears different.
> If a `drop()` step appears after a `union()` step, Gremlin does not drop all
> of the vertices that flow out of the `union()`. It only drops one vertex.
>
> For example, using the air routes data, we can see that V(44) has four
> outgoing routes, and the `union()` correctly yields five results. However, if
> a `drop()` is performed after the `union()` only V(44) gets dropped. As a
> workaround, doing `union().fold().unfold().drop()` does work and all five
> vertices get deleted.
>
> {code:java}
> gremlin> g.V().count()
> ==>3748
> gremlin> g.V(44).union(identity(),out()).count()
> ==>5
> gremlin> g.V(44).union(identity(),out()).drop()
> // Only one has been dropped
> gremlin> g.V().count()
> ==>3747 {code}
> We can see by profiling the two queries that the number of traversers stays
> at one, if a drop() step is present, whereas it is five otherwise.
> {code:java}
> gremlin> g.V(44).union(identity(),out()).profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms) % Dur
> =
> TinkerGraphStep(vertex,[44]) 1
> 1 0.255 26.98
> UnionStep([[IdentityStep, EndStep], [VertexStep... 5
> 5 0.691 73.02
> IdentityStep 1
> 1 0.017
> EndStep 1
> 1 0.014
> VertexStep(OUT,vertex) 4
> 4 0.069
> EndStep 4
> 4 0.072
> >TOTAL -
> - 0.947 -
> gremlin> g.V(44).union(identity(),out()).drop().profile()
> ==>Traversal Metrics
> Step Count
> Traversers Time (ms) % Dur
> =
> TinkerGraphStep(vertex,[44]) 1
> 1 0.073 19.44
> UnionStep([[IdentityStep, EndStep], [VertexStep... 1
> 1 0.159 42.40
> IdentityStep 1
> 1 0.006
> EndStep 1
> 1 0.009
> VertexStep(OUT,vertex)
> 0.025
> EndStep
> 0.016
> DropStep
> 0.143 38.16
> >TOTAL -
> - 0.376 -
> gremlin> {code}
>
> This issue was also reported via a StackOverflow post:
> [https://stackoverflow.com/questions/74238687/why-does-my-gremlin-query-not-drop-all-the-vertices-i-indicate]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2359) onShutDown not being called when docker container stopped
[ https://issues.apache.org/jira/browse/TINKERPOP-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia updated TINKERPOP-2359: Priority: Critical (was: Minor) > onShutDown not being called when docker container stopped > - > > Key: TINKERPOP-2359 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2359 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.4.6 >Reporter: ohad israeli >Priority: Critical > > When one uses groovy hooks with tinkerpop server hosted within the official > docker the onStartUp hook will be called at server startup but the onShutDown > will not be called. > I am using tinkergraph server for local testing and i would like to persist > the data upon the server exit. i've added a graph.close to the onShutDown > hook but i havent been able to get it called. > It will be called of course if you use the server start / server stop shell > script but not if you kill / stop the docker container. > If there is some other way to persist the date i.e. call the graph.close from > code and note via the console it would also be great as using it from node > javascript i havent been able to find a way to call the graph.close directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-2359) onShutDown not being called when docker container stopped
[ https://issues.apache.org/jira/browse/TINKERPOP-2359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia reassigned TINKERPOP-2359: --- Assignee: Cole Greer > onShutDown not being called when docker container stopped > - > > Key: TINKERPOP-2359 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2359 > Project: TinkerPop > Issue Type: Bug > Components: server >Affects Versions: 3.4.6 >Reporter: ohad israeli >Assignee: Cole Greer >Priority: Critical > > When one uses groovy hooks with tinkerpop server hosted within the official > docker the onStartUp hook will be called at server startup but the onShutDown > will not be called. > I am using tinkergraph server for local testing and i would like to persist > the data upon the server exit. i've added a graph.close to the onShutDown > hook but i havent been able to get it called. > It will be called of course if you use the server start / server stop shell > script but not if you kill / stop the docker container. > If there is some other way to persist the date i.e. call the graph.close from > code and note via the console it would also be great as using it from node > javascript i havent been able to find a way to call the graph.close directly. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2773) Automate loading dependencies for Hadoop on Windows
[ https://issues.apache.org/jira/browse/TINKERPOP-2773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yang Xia closed TINKERPOP-2773. --- Resolution: Won't Do > Automate loading dependencies for Hadoop on Windows > --- > > Key: TINKERPOP-2773 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2773 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.5.3 > Environment: Windows >Reporter: Rithin Kumar R S >Priority: Minor > > Currently, for developers on Windows, winutils for Hadoop must be manually > downloaded and set up. This process should ideally happen automatically > without the user needing to manually download and set up files. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2634) Improve the ability to debug Gremlin traversals
[
https://issues.apache.org/jira/browse/TINKERPOP-2634?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2634.
---
Resolution: Won't Do
> Improve the ability to debug Gremlin traversals
> ---
>
> Key: TINKERPOP-2634
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2634
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.5.1
>Reporter: Stephen Mallette
>Priority: Major
>
> Introduce a new {{DebugStrategy}} which would essentially place the traversal
> in development mode. It would be added in the Gremlin Console when defining
> "g" or in a developer’s application code during programming. This approach
> works nicely for application development because it could be added in a way
> that doesn’t interfere with the execution of the code allowing tests to run
> without modification. For example, there would be no need to tack a
> {{profile()}} to the end of a traversal after discovering a problem or a need
> to take the traversal to a different tool to try to debug it.
> {code}
> g.withStrategy(DebugStrategy)
> g.withStrategy(new DebugStrategy(verifyEdgeLabelSpecification=true,
> includeProfile=false))
> g.withDebug() - first class??
> {code}
> If your tests all pass in development, the developer would be assured that
> running the same code in production without {{DebugStrategy}} would be safe.
> {{DebugStrategy}} could perhaps always turn on {{profile()}} but still return
> results and preserve the profiling output to be retrieved from the traversal
> somehow. Some more thought needs to be applied here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (TINKERPOP-2628) Gremlin test suite run on Windows
[
https://issues.apache.org/jira/browse/TINKERPOP-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia reopened TINKERPOP-2628:
-
> Gremlin test suite run on Windows
> -
>
> Key: TINKERPOP-2628
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2628
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.5.2
> Environment: OS: Windows
>Reporter: Davide Riva
>Priority: Minor
> Attachments: correct_comparison_of_file_output_with__r_n.patch,
> correct_string_interpolation_for_file_path_issues.patch,
> correct_string_interpolation_for_file_path_issues1.patch
>
>
> Currently, there are some tests (IoReader or IoWrite) which always fail on
> Windows. This is probably due to how temporary folders are created
> How to reproduce: run IoReader or IoWriter on Windows on a particular
> implementation ({{mvn clean test}} should be sufficient)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2628) Gremlin test suite run on Windows
[
https://issues.apache.org/jira/browse/TINKERPOP-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2628.
---
Resolution: Fixed
> Gremlin test suite run on Windows
> -
>
> Key: TINKERPOP-2628
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2628
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.5.2
> Environment: OS: Windows
>Reporter: Davide Riva
>Priority: Minor
> Attachments: correct_comparison_of_file_output_with__r_n.patch,
> correct_string_interpolation_for_file_path_issues.patch,
> correct_string_interpolation_for_file_path_issues1.patch
>
>
> Currently, there are some tests (IoReader or IoWrite) which always fail on
> Windows. This is probably due to how temporary folders are created
> How to reproduce: run IoReader or IoWriter on Windows on a particular
> implementation ({{mvn clean test}} should be sufficient)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2628) Gremlin test suite run on Windows
[
https://issues.apache.org/jira/browse/TINKERPOP-2628?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2628.
---
Resolution: Fixed
TinkerPop can now be built on Windows, this should be resolved.
> Gremlin test suite run on Windows
> -
>
> Key: TINKERPOP-2628
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2628
> Project: TinkerPop
> Issue Type: Bug
> Components: build-release
>Affects Versions: 3.5.2
> Environment: OS: Windows
>Reporter: Davide Riva
>Priority: Minor
> Attachments: correct_comparison_of_file_output_with__r_n.patch,
> correct_string_interpolation_for_file_path_issues.patch,
> correct_string_interpolation_for_file_path_issues1.patch
>
>
> Currently, there are some tests (IoReader or IoWrite) which always fail on
> Windows. This is probably due to how temporary folders are created
> How to reproduce: run IoReader or IoWriter on Windows on a particular
> implementation ({{mvn clean test}} should be sufficient)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2618) Refactor Java Driver to use the Netty FixedSizeConnectionPool
[
https://issues.apache.org/jira/browse/TINKERPOP-2618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2618.
---
Resolution: Won't Do
> Refactor Java Driver to use the Netty FixedSizeConnectionPool
> -
>
> Key: TINKERPOP-2618
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2618
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.4.12
>Reporter: Stephen Mallette
>Priority: Minor
>
> The Java driver currently has it's own {{ConnectionPool}} implementation.
> Determine if using the netty {{FixedSizeConnectionPool}} allows us to drop
> our pool and implement it should it be smart to do so. This task should
> probably include a modicum of performance testing to ensure there are no
> adverse effects from the change. Presumably this is a non-breaking change and
> can go to 3.5.x, but if not, then it should probably point at 3.6.0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2617) Refactor Java Driver to have one method for connection selection
[
https://issues.apache.org/jira/browse/TINKERPOP-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17769799#comment-17769799
]
ASF GitHub Bot commented on TINKERPOP-2617:
---
xiazcy commented on PR #1709:
URL: https://github.com/apache/tinkerpop/pull/1709#issuecomment-1738061207
Been open for a while with not much activity, we are closing this PR.
> Refactor Java Driver to have one method for connection selection
>
>
> Key: TINKERPOP-2617
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2617
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.4.12
>Reporter: Stephen Mallette
>Priority: Minor
>
> To make a decision on whether a connection should be borrowed or not, a Java
> client today does two logic which are different from each other. They should
> both be same. One bit of logic to do so is at:
> {code}
> if (borrowed >= maxSimultaneousUsagePerConnection &&
> leastUsedConn.availableInProcess() == 0) {
> {code}
> and another is:
> {code}
> final int inFlight = leastUsed.borrowed.get();
> final int availableInProcess =
> leastUsed.availableInProcess();
> if (inFlight >= availableInProcess) {
> logger.debug("Least used {} on {} has requests
> borrowed [{}] >= availableInProcess [{}] - may timeout waiting for
> connection",
> leastUsed, host, inFlight,
> availableInProcess);
> break;
> }
> if (leastUsed.borrowed.compareAndSet(inFlight, inFlight +
> 1)) {
> if (logger.isDebugEnabled())
> logger.debug("Return least used {} on {} after
> waiting", leastUsed.getConnectionInfo(), host);
> return leastUsed;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2617) Refactor Java Driver to have one method for connection selection
[
https://issues.apache.org/jira/browse/TINKERPOP-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2617.
---
Resolution: Won't Do
Closing. Please re-open if needed.
> Refactor Java Driver to have one method for connection selection
>
>
> Key: TINKERPOP-2617
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2617
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.4.12
>Reporter: Stephen Mallette
>Priority: Minor
>
> To make a decision on whether a connection should be borrowed or not, a Java
> client today does two logic which are different from each other. They should
> both be same. One bit of logic to do so is at:
> {code}
> if (borrowed >= maxSimultaneousUsagePerConnection &&
> leastUsedConn.availableInProcess() == 0) {
> {code}
> and another is:
> {code}
> final int inFlight = leastUsed.borrowed.get();
> final int availableInProcess =
> leastUsed.availableInProcess();
> if (inFlight >= availableInProcess) {
> logger.debug("Least used {} on {} has requests
> borrowed [{}] >= availableInProcess [{}] - may timeout waiting for
> connection",
> leastUsed, host, inFlight,
> availableInProcess);
> break;
> }
> if (leastUsed.borrowed.compareAndSet(inFlight, inFlight +
> 1)) {
> if (logger.isDebugEnabled())
> logger.debug("Return least used {} on {} after
> waiting", leastUsed.getConnectionInfo(), host);
> return leastUsed;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-2617) Refactor Java Driver to have one method for connection selection
[
https://issues.apache.org/jira/browse/TINKERPOP-2617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17769800#comment-17769800
]
ASF GitHub Bot commented on TINKERPOP-2617:
---
xiazcy closed pull request #1709: TINKERPOP-2617 Clean up Java connection pool
logic
URL: https://github.com/apache/tinkerpop/pull/1709
> Refactor Java Driver to have one method for connection selection
>
>
> Key: TINKERPOP-2617
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2617
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.4.12
>Reporter: Stephen Mallette
>Priority: Minor
>
> To make a decision on whether a connection should be borrowed or not, a Java
> client today does two logic which are different from each other. They should
> both be same. One bit of logic to do so is at:
> {code}
> if (borrowed >= maxSimultaneousUsagePerConnection &&
> leastUsedConn.availableInProcess() == 0) {
> {code}
> and another is:
> {code}
> final int inFlight = leastUsed.borrowed.get();
> final int availableInProcess =
> leastUsed.availableInProcess();
> if (inFlight >= availableInProcess) {
> logger.debug("Least used {} on {} has requests
> borrowed [{}] >= availableInProcess [{}] - may timeout waiting for
> connection",
> leastUsed, host, inFlight,
> availableInProcess);
> break;
> }
> if (leastUsed.borrowed.compareAndSet(inFlight, inFlight +
> 1)) {
> if (logger.isDebugEnabled())
> logger.debug("Return least used {} on {} after
> waiting", leastUsed.getConnectionInfo(), host);
> return leastUsed;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2590) ClassCastException when specifying "single cardinality" for edge property
[
https://issues.apache.org/jira/browse/TINKERPOP-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2590:
Priority: Major (was: Trivial)
> ClassCastException when specifying "single cardinality" for edge property
> -
>
> Key: TINKERPOP-2590
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2590
> Project: TinkerPop
> Issue Type: Bug
> Components: structure
>Affects Versions: 3.4.8
>Reporter: Christopher Smith
>Priority: Major
>
> As I understand it, multi-properties are not supported on edges in Tinkerpop,
> and this is an understandable limitation. However, my expectation as an API
> client is that if I redundantly specify {{Cardinality.single}} when setting a
> property on an edge, it would succeed silently. Instead
> {{AddPropertyStep.java:151,153}} (as of 3.4.8) unconditionally casts the
> traversal element to {{Vertex}} on seeing any {{Cardinality}} at all,
> producing a confusing {{ClassCastException}}.
> (1) In the case of {{single}}, which specifies the correct semantics, the
> call should succeed. (This is relevant when trying to reuse a method to
> update a single-valued timestamp on a generic {{Element}}.)
> (2) It would be a major improvement to debugging to, instead of performing
> inline casting, use a wrapper method producing an error message such as
> "property cardinality may only be specified for a Vertex".
> There are many cases throughout the code where (2) applies; would you be
> interested in contributions to retrofit enhanced error messages?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2590) ClassCastException when specifying "single cardinality" for edge property
[
https://issues.apache.org/jira/browse/TINKERPOP-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2590:
Priority: Trivial (was: Major)
> ClassCastException when specifying "single cardinality" for edge property
> -
>
> Key: TINKERPOP-2590
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2590
> Project: TinkerPop
> Issue Type: Bug
> Components: structure
>Affects Versions: 3.4.8
>Reporter: Christopher Smith
>Priority: Trivial
>
> As I understand it, multi-properties are not supported on edges in Tinkerpop,
> and this is an understandable limitation. However, my expectation as an API
> client is that if I redundantly specify {{Cardinality.single}} when setting a
> property on an edge, it would succeed silently. Instead
> {{AddPropertyStep.java:151,153}} (as of 3.4.8) unconditionally casts the
> traversal element to {{Vertex}} on seeing any {{Cardinality}} at all,
> producing a confusing {{ClassCastException}}.
> (1) In the case of {{single}}, which specifies the correct semantics, the
> call should succeed. (This is relevant when trying to reuse a method to
> update a single-valued timestamp on a generic {{Element}}.)
> (2) It would be a major improvement to debugging to, instead of performing
> inline casting, use a wrapper method producing an error message such as
> "property cardinality may only be specified for a Vertex".
> There are many cases throughout the code where (2) applies; would you be
> interested in contributions to retrofit enhanced error messages?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-2590) ClassCastException when specifying "single cardinality" for edge property
[
https://issues.apache.org/jira/browse/TINKERPOP-2590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia updated TINKERPOP-2590:
Priority: Trivial (was: Major)
> ClassCastException when specifying "single cardinality" for edge property
> -
>
> Key: TINKERPOP-2590
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2590
> Project: TinkerPop
> Issue Type: Bug
> Components: structure
>Affects Versions: 3.4.8
>Reporter: Christopher Smith
>Priority: Trivial
>
> As I understand it, multi-properties are not supported on edges in Tinkerpop,
> and this is an understandable limitation. However, my expectation as an API
> client is that if I redundantly specify {{Cardinality.single}} when setting a
> property on an edge, it would succeed silently. Instead
> {{AddPropertyStep.java:151,153}} (as of 3.4.8) unconditionally casts the
> traversal element to {{Vertex}} on seeing any {{Cardinality}} at all,
> producing a confusing {{ClassCastException}}.
> (1) In the case of {{single}}, which specifies the correct semantics, the
> call should succeed. (This is relevant when trying to reuse a method to
> update a single-valued timestamp on a generic {{Element}}.)
> (2) It would be a major improvement to debugging to, instead of performing
> inline casting, use a wrapper method producing an error message such as
> "property cardinality may only be specified for a Vertex".
> There are many cases throughout the code where (2) applies; would you be
> interested in contributions to retrofit enhanced error messages?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2508) Support case-insensitive predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2508.
---
Resolution: Duplicate
> Support case-insensitive predicates
> ---
>
> Key: TINKERPOP-2508
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2508
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.9
>Reporter: Christopher Smith
>Priority: Major
>
> [As noted|https://stackoverflow.com/a/58103202/1189885], Gremlin has no
> native means to express case-insensitive text predicates. While I understand
> the caution shown in not running ahead of the capabilities in various
> backends, the inability to express even a simple case-insensitive prefix
> search natively is a major impediment when using platforms like Neptune that
> entirely disallow lambda operations. Even if the search were entirely
> unindexed, it would be drastically more efficient to execute a scan-style
> traversal on the server rather than any of the other potential options.
> As an adjunct, "case-insensitive operations" could be listed as a graph
> feature alongside {{Computer}} and {{Transactions}}, providing the ability to
> either prohibit such steps or to slurp locally via strategy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (TINKERPOP-2509) Uppercase/lowercase modulators
[
https://issues.apache.org/jira/browse/TINKERPOP-2509?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yang Xia closed TINKERPOP-2509.
---
Resolution: Duplicate
String manipulation functions will now allow toUpper() and toLower(), should
satisfy current needs.
> Uppercase/lowercase modulators
> --
>
> Key: TINKERPOP-2509
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2509
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.9
>Reporter: Christopher Smith
>Priority: Minor
>
> As an alternative/adjunct to more backend-involved features like
> case-insensitive search, it would be helpful to have modulators (or is it
> operators? with-options?) {{uppercase}} and {{lowercase}} that could be
> applied arbitrarily in the same way that other modulators are. This would,
> among other things, allow for more efficient loads of indexed values (e.g.,
> an unfolded traversal that selected certain properties, prefixed them with
> {{lc.}}, and saved the lowercase value for later query) and for
> less-inefficient server-side case-insensitive traversals of values that are
> inherently case-sensitive (by doing a full scan, but still server-side).
> Based on the architecture, it _seems_ that adding support for these
> modulators would be minimally invasive for backend systems, in contrast to
> richer features.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[DISCUSS] Transition to Semantic Versioning
Hi everyone, I think now is a good time to start thinking about 3.7.x development from master into 3.7-dev and to setup master to take breaking changes for the next major release. I opted to delay this after the last release to temporarily save some of the admin burden of 4 active branches. I think this gives a good opportunity to revisit our versioning scheme. The current scheme (https://tinkerpop.apache.org/docs/current/dev/developer/#versioning) is EPOCH.MAJOR.MINOR.PATCH, where EPOCH has been fixed at 3 since 2015, and the PATCH digit has never been utilized. I suggest that we move to a more standard semantic versioning scheme (https://semver.org/) with just MAJOR.MINOR.PATCH starting with 4.0.0. I would expect the MAJOR and MINOR numbers to essentially retain the same roles as they have now (4.x.x -> 5.0.0 would be comparable to 3.6.x -> 3.7.0). I don’t expect we would utilize the PATCH release often, but I would for it to be a formalized process for publishing partial releases (perhaps only updating a single component) which can hopefully skip much of the overhead of a full release. We’ve previously deployed release-candidate convenience binaries for some GLV’s in the past for certain users in this fashion, it would be good to bring this into a proper release. I believe this versioning system is more aligned with what most developers are used to. Additionally, I hope that dropping the EPOCH value will allow us to be a little more aggressive with changes in major releases (perhaps introducing a type system or schema capability). It would also be useful if we started publishing end-of-life dates for major releases to give users a clearer picture of expected support. I would suggest as a starting point 1 year of active support (adding new features, acting as the main target branch for non-breaking changes) and 2 years of security support (branch is kept open for critical bug fixes and security patches). If we plan to maintain roughly 1 major release per year, this remains somewhat in line with current support timelines. We would presumably retain the right to do additional releases for a branch beyond the promised support window if we ever deemed it necessary. Let me know if you have any thoughts on this change. If there is no feedback, I will assume a lazy consensus in favour of adopting semantic versioning and moving the master branch to 4.0.0-SNAPSHOT development. There are still some details to be worked out regarding patch releases under the new system (it isn’t completely fleshed out for the current system either). I intend to follow up soon with a more specific patch release proposal depending on the feedback here. Thanks, Cole Greer
Re: [DISCUSS] Transition to Semantic Versioning
What about CalVer? https://calver.org/ There have been TinkerPop versions in the past which were quite different 1, 2, 3. I would expect a version 4 (as some proposals suggested). It seems that this major version number is part of the product name more than just a version. On Wed, Sep 27, 2023 at 4:14 PM Cole Greer wrote: > Hi everyone, > > I think now is a good time to start thinking about 3.7.x development from > master into 3.7-dev and to setup master to take breaking changes for the > next major release. I opted to delay this after the last release to > temporarily save some of the admin burden of 4 active branches. > > I think this gives a good opportunity to revisit our versioning scheme. > The current scheme ( > https://tinkerpop.apache.org/docs/current/dev/developer/#versioning) is > EPOCH.MAJOR.MINOR.PATCH, where EPOCH has been fixed at 3 since 2015, and > the PATCH digit has never been utilized. > > I suggest that we move to a more standard semantic versioning scheme ( > https://semver.org/) with just MAJOR.MINOR.PATCH starting with 4.0.0. I > would expect the MAJOR and MINOR numbers to essentially retain the same > roles as they have now (4.x.x -> 5.0.0 would be comparable to 3.6.x -> > 3.7.0). I don’t expect we would utilize the PATCH release often, but I > would for it to be a formalized process for publishing partial releases > (perhaps only updating a single component) which can hopefully skip much of > the overhead of a full release. We’ve previously deployed release-candidate > convenience binaries for some GLV’s in the past for certain users in this > fashion, it would be good to bring this into a proper release. > > I believe this versioning system is more aligned with what most developers > are used to. Additionally, I hope that dropping the EPOCH value will allow > us to be a little more aggressive with changes in major releases (perhaps > introducing a type system or schema capability). > > It would also be useful if we started publishing end-of-life dates for > major releases to give users a clearer picture of expected support. I would > suggest as a starting point 1 year of active support (adding new features, > acting as the main target branch for non-breaking changes) and 2 years of > security support (branch is kept open for critical bug fixes and security > patches). If we plan to maintain roughly 1 major release per year, this > remains somewhat in line with current support timelines. We would > presumably retain the right to do additional releases for a branch beyond > the promised support window if we ever deemed it necessary. > > Let me know if you have any thoughts on this change. If there is no > feedback, I will assume a lazy consensus in favour of adopting semantic > versioning and moving the master branch to 4.0.0-SNAPSHOT development. > There are still some details to be worked out regarding patch releases > under the new system (it isn’t completely fleshed out for the current > system either). I intend to follow up soon with a more specific patch > release proposal depending on the feedback here. > > Thanks, > > Cole Greer >
