[jira] [Commented] (TINKERPOP-2710) hasKey() should throw an error when invoked on Elements
[
https://issues.apache.org/jira/browse/TINKERPOP-2710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17508899#comment-17508899
]
Kelvin R. Lawrence commented on TINKERPOP-2710:
---
I'm not quite sure what the best thing to do here is. Would it perhaps make
sense to deprecate `hasKey` completely and have `has` work on `Property` types
as well as Element types? If that does not make sense, I think I would be in
favor of having `hasKey` work the way `has` does with Elements rather than
error.
I agree on throwing less errors, that has been a focus lately - to filter
rather than throw - where appropriate. Some cases will still error, but perhaps
even these could be filtered as well. Such as:
{code:java}
gremlin> g.V().constant(1).has('date')
java.lang.Integer cannot be cast to
org.apache.tinkerpop.gremlin.structure.Element {code}
> hasKey() should throw an error when invoked on Elements
> ---
>
> Key: TINKERPOP-2710
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2710
> Project: TinkerPop
> Issue Type: Bug
> Components: language, process
>Affects Versions: 3.6.0
>Reporter: Divij Vaidya
>Priority: Major
>
> *Context*
> hasKey() step can be added to the traversal when the traverser is of type
> Element or when it is of type Property.
> When step is invoked for traverser of type property, the behaviour is well
> defined as, "Remove the {{Property}} traverser if it does not match one of
> the provided keys." Example query:
> {noformat}
> gremlin> g.V().properties().hasKey('age').value()
> ==>29
> ==>27
> ==>32
> ==>35{noformat}
> When the step is invoked for traverser of type Element, the behaviour of the
> step is not documented. [Looking at the
> code|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
> implementation, it "removes the element traverser if element has a property
> with key as '~key' and the value of that property matches 'age'".
> But [this condition is
> unsatisfiable|https://github.com/apache/tinkerpop/blob/6a0b71b2af79b1b45f1e2db41946fe85529ed32e/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/ElementHelper.java#L84]
> because Element can never have a property with key "~key". It would always
> fail at insertion i.e. the output of hasKey() on Element traverser will
> always be empty.
> *Change proposed*
> Hence, I propose the following change:
> If hasKey() is applied to a traverser of Element type, then it should throw
> an error.
> The code change will be made
> [here|https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/util/HasContainer.java#L59]
> . We would introduce a change as follows:
> {noformat}
> if (this.key.equals(T.key.getAccessor())) {
> throw new IllegalArgumentException("hasKey() cannot be applied to
> traverser of type Element")
> }{noformat}
> *Impact of the change*
> Before the change:
> {noformat}
> // the following query always returns empty results gremlin>
> g.V().hasKey('age').fold()
> gremlin> g.V().hasKey('age').fold()
> ==>[]{noformat}
>
> After the change:
> {noformat}
> // the following query returns an error
> gremlin> g.V().hasKey('age').fold()
> hasKey() cannot be applied to traverser of type Element{noformat}
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2716) Enable eslint for gremlin-javascript project
[ https://issues.apache.org/jira/browse/TINKERPOP-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17502559#comment-17502559 ] Kelvin R. Lawrence commented on TINKERPOP-2716: --- Thanks for creating the issue. Saw that [~jorgebg] was OK with enabling ES lint. Are planning to submit a PR for that? > Enable eslint for gremlin-javascript project > > > Key: TINKERPOP-2716 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2716 > Project: TinkerPop > Issue Type: Bug > Components: javascript >Affects Versions: 3.5.2 >Reporter: Tom Kolanko >Priority: Minor > > The gremlin-javascript project has no linter set so it's easy for code to be > formatted differently depending on the editor used to save the changes > From https://github.com/apache/tinkerpop/pull/1539#discussion_r818682368 we > can implement eslint + airbnb's config to have a standard which editors would > be able to pick up -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (TINKERPOP-2716) Enable eslint for gremlin-javascript project
[ https://issues.apache.org/jira/browse/TINKERPOP-2716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence updated TINKERPOP-2716: -- Fix Version/s: (was: 3.6.0) > Enable eslint for gremlin-javascript project > > > Key: TINKERPOP-2716 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2716 > Project: TinkerPop > Issue Type: Bug > Components: javascript >Affects Versions: 3.5.2 >Reporter: Tom Kolanko >Priority: Minor > > The gremlin-javascript project has no linter set so it's easy for code to be > formatted differently depending on the editor used to save the changes > From https://github.com/apache/tinkerpop/pull/1539#discussion_r818682368 we > can implement eslint + airbnb's config to have a standard which editors would > be able to pick up -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (TINKERPOP-2715) remove log4jv1 dependency
[ https://issues.apache.org/jira/browse/TINKERPOP-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence updated TINKERPOP-2715: -- Component/s: build-release > remove log4jv1 dependency > - > > Key: TINKERPOP-2715 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2715 > Project: TinkerPop > Issue Type: Improvement > Components: build-release >Affects Versions: 3.5.2 >Reporter: PJ Fanning >Priority: Major > > Can this be reconsidered? Log4jv1 has even more open CVEs now. > [https://repo1.maven.org/maven2/org/apache/tinkerpop/gremlin-driver/3.5.2/gremlin-driver-3.5.2.pom] > https://issues.apache.org/jira/browse/TINKERPOP-1983 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (TINKERPOP-2715) remove log4jv1 dependency
[ https://issues.apache.org/jira/browse/TINKERPOP-2715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence updated TINKERPOP-2715: -- Affects Version/s: 3.5.2 > remove log4jv1 dependency > - > > Key: TINKERPOP-2715 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2715 > Project: TinkerPop > Issue Type: Improvement >Affects Versions: 3.5.2 >Reporter: PJ Fanning >Priority: Major > > Can this be reconsidered? Log4jv1 has even more open CVEs now. > [https://repo1.maven.org/maven2/org/apache/tinkerpop/gremlin-driver/3.5.2/gremlin-driver-3.5.2.pom] > https://issues.apache.org/jira/browse/TINKERPOP-1983 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Closed] (TINKERPOP-2679) Update JavaScript driver to support processing messages as a stream
[
https://issues.apache.org/jira/browse/TINKERPOP-2679?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin R. Lawrence closed TINKERPOP-2679.
-
Fix Version/s: 3.6.0
3.5.3
Assignee: Jorge Bay
Resolution: Fixed
> Update JavaScript driver to support processing messages as a stream
> ---
>
> Key: TINKERPOP-2679
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2679
> Project: TinkerPop
> Issue Type: Improvement
> Components: javascript
>Affects Versions: 3.5.1
>Reporter: Tom Kolanko
>Assignee: Jorge Bay
>Priority: Minor
> Fix For: 3.6.0, 3.5.3
>
>
> The JavaScript driver's
> [_handleMessage|https://github.com/apache/tinkerpop/blob/d4bd5cc5a228fc22442101ccb6a9751653900d32/gremlin-javascript/src/main/javascript/gremlin-javascript/lib/driver/connection.js#L249]
> receives messages from the gremlin server and stores each message in an
> object associated with the handler for the specific request. Currently, the
> driver waits until all the data is available from the gremlin server before
> allowing further processing of it.
> However, this can lead to cases where a lot of memory is required to hold
> onto the results before any processing can take place. If we had the abilty
> to process results as they come in from the gremlin server we could reduce
> memory in some cases
> If you are open to it I would like to submit a PR where {{submit}} can take
> an optional callback which is run on each set of data returned from the
> gremlin server, rather than waiting for the entire result set.
> The following examples assume that you have 100 vertices in your graph.
> current behaviour:
> {code:javascript}
> const result = await client.submit("g.V()")
> console.log(result.toArray()) // 100 - all the vertices in your graph
> {code}
> proposed addition
> {code:javascript}
> await client.submit("g.V()", {}, { batchSize: 25 }, (data) => {
> console.log(data.toArray().length) // 25 - this callback will be called 4
> times (100 / 25 = 4)
> })
> {code}
> If the optional callback is not provided then the default behaviour is
> unchanged
> I have the changes running locally and the overall performance is unchanged,
> queries run about the same as they used to, however, for some specific
> queries memory usage has dropped considerably.
> With the process-on-message strategy the memory usage will be related to how
> large the {{batchSize}} is rather than the final result set. Using the
> default of 64 and testing some specific cases we have I can get the memory to
> go from 1.2gb to 10mb.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2674) `as('a')` step followed by `select('a')` not behaving as expected
[
https://issues.apache.org/jira/browse/TINKERPOP-2674?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17464807#comment-17464807
]
Kelvin R. Lawrence commented on TINKERPOP-2674:
---
You are using simplePath. When you do the select you are introducing the same
vertex into the path twice. Hence no results as there are no longer any simple
paths
> `as('a')` step followed by `select('a')` not behaving as expected
> -
>
> Key: TINKERPOP-2674
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2674
> Project: TinkerPop
> Issue Type: Bug
> Components: tinkergraph
>Affects Versions: 3.5.1
>Reporter: Fredrick Eisele
>Priority: Major
>
> The inclusion of the `select()` step changes the result when it should not.
> Steps to replicate.
> Given a graph:
> {code:groovy}
> g.addV('[avm]Design').as('root').
> property('VertexLabel','[avm]Design').
> property('uuid','SRC_UUID').
> property('[]Name', 'Axe').
> addV('[]RootContainer').as('rc').
> property('VertexLabel','[]RootContainer').
> property('[]Name','Axe').
> addV('[]Property').as('p1').
> property('VertexLabel','[]Property').
> property('[]XPosition','56').
> addV('[]Value').as('v1').
> property('VertexLabel','[]Value').
> property('[]stuff','12').
> addV('[]Property').as('p2').
> property('VertexLabel','[]Property').
> property('[]XPosition','80').
> addV('[]Value').as('v2').
> property('VertexLabel','[]Value').
> property('[]stuff','90').
> addE('inside').from('rc').to('root').
> addE('inside').from('p1').to('rc').
> addE('inside').from('v1').to('p1').
> addE('inside').from('p2').to('rc').
> addE('inside').from('v2').to('p2').
> iterate()
> {code}
> The following two queries {color:#FF}*incorrectly*{color} produce
> different results.
> This first query produces a list of all the vertices with the exception of
> 'r0'.
> {code:groovy}
> g.V().
> has('[avm]Design', 'uuid', 'SRC_UUID').as('r0').
> repeat(__.in('inside').simplePath()).
> emit().
> until(__.in('inside').count().is(0)).
> toList()
> {code}
> The addition of the `select('r0')` step in this query causes no vertices to
> be returned.
> {code:groovy}
> g.V().
> has('[avm]Design', 'uuid', 'SRC_UUID').as('r0').
> select('r0').
> repeat(__.in('inside').simplePath()).
> emit().
> until(__.in('inside').count().is(0)).
> toList()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (TINKERPOP-2631) GraphSON float serialization when ujson is used is imprecise
[
https://issues.apache.org/jira/browse/TINKERPOP-2631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17433852#comment-17433852
]
Kelvin R. Lawrence commented on TINKERPOP-2631:
---
This sounds reasonable. If that version passes the test-suite I would feel
comfortable bumping the version. I don't know the history behind using `ujson`
but I assume it was to get the speedup of an "all in C" library. Would you be
able to submit a PR and run the test suite to verify nothing breaks? I prefer
not to have optional dependencies. I would prefer we favor a version known to
work (>= 2.0 would be fine probably but maybe just ==2.0 for now). As this
would change the behavior of the serializer (albeit in a good way) this is a
breaking change so should probably target the mainline [~spmallette] ?
> GraphSON float serialization when ujson is used is imprecise
>
>
> Key: TINKERPOP-2631
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2631
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.5.1
>Reporter: Clément de Groc
>Priority: Minor
>
> h1. Problem
> When submitting traversals including float values, the GraphSON-serialized
> traversal truncates them:
> {code:java}
> g.V().has("id", "X").property("popularity", 0.09).iterate(){code}
> is serialized to
>
> {code:java}
> {"gremlin":{"@type":"g:Bytecode","@value":{"source":[],"step":[["V"],["has","id","X"],["property","popularity",{"@type":"g:Double","@value":0.1}],["none"]]}},"processor":"traversal"}
> {code}
> h1. Cause
> In
> {{[gremlin_python/driver/serializer.py|https://github.com/apache/tinkerpop/blob/master/gremlin-python/src/main/python/gremlin_python/driver/serializer.py#L19-L22]}}
> (but also {{protocol.py}} in passing), {{ujson}} is imported in place of
> stdlib {{json}}:
> {code:java}
> try:
> import ujson as json
> except ImportError:
> import json
> {code}
> This is certainly done for performance reasons, but this has an impact on
> floating point precision.
> With {{ujson <}} 2.0, if \{{precise_float }}is not specified (which is the
> case):
> {code:java}
> ujson.dumps(0.09) == '0.1'{code}
> With {{ujson}} >= 2.0, out-of-the-box floating point precision was improved:
> {code:java}
> ujson.dumps(0.09) == '0.09'{code}
> Here is the change in ujson explaining the difference:
> [ultrajson/ultrajson@{{eb7d894}}|https://github.com/ultrajson/ultrajson/commit/eb7d894f225bb89d269188ba6ec559b914a71b8a]
> h1. Potential solution
> Could {{ujson}} be listed as an optional dependency in {{setup.py}} with
> version >= 2.0 ?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2594) Antlr Grammar missing support for Direction enum prefix
Kelvin R. Lawrence created TINKERPOP-2594: - Summary: Antlr Grammar missing support for Direction enum prefix Key: TINKERPOP-2594 URL: https://issues.apache.org/jira/browse/TINKERPOP-2594 Project: TinkerPop Issue Type: Improvement Components: language Affects Versions: 3.5.0 Reporter: Kelvin R. Lawrence The Antlr grammar recognizes things like `Scope.local` or just `local`. However for `Direction` only the basic members like `IN` and `OUT` are recognized. `Direction.OUT` is not recognized. For the sake of consistency we should fix this and at the same time look for any other similar cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (TINKERPOP-2527) Add a GroovyTranslator equivalent method to the Python client
[ https://issues.apache.org/jira/browse/TINKERPOP-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence closed TINKERPOP-2527. - Changes are now merged into the mainline > Add a GroovyTranslator equivalent method to the Python client > - > > Key: TINKERPOP-2527 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2527 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.5.0 >Reporter: Kelvin R. Lawrence >Assignee: Kelvin R. Lawrence >Priority: Major > Fix For: 3.5.0 > > > Currently there is no equivalent to GroovyTranslator for the Gremlin Python > client. There is one in the JavaScript client however. Adding one for the > Python client will further help in moving all the clients to a consistent > level of functionality. I have this mostly coded up and will try to submit > some code within the next few days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (TINKERPOP-2527) Add a GroovyTranslator equivalent method to the Python client
[ https://issues.apache.org/jira/browse/TINKERPOP-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence resolved TINKERPOP-2527. --- Resolution: Fixed Changes merged into master. > Add a GroovyTranslator equivalent method to the Python client > - > > Key: TINKERPOP-2527 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2527 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.5.0 >Reporter: Kelvin R. Lawrence >Assignee: Kelvin R. Lawrence >Priority: Major > Fix For: 3.5.0 > > > Currently there is no equivalent to GroovyTranslator for the Gremlin Python > client. There is one in the JavaScript client however. Adding one for the > Python client will further help in moving all the clients to a consistent > level of functionality. I have this mostly coded up and will try to submit > some code within the next few days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2527) Add a GroovyTranslator equivalent method to the Python client
[ https://issues.apache.org/jira/browse/TINKERPOP-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence updated TINKERPOP-2527: -- Fix Version/s: 3.5.0 > Add a GroovyTranslator equivalent method to the Python client > - > > Key: TINKERPOP-2527 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2527 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.5.0 >Reporter: Kelvin R. Lawrence >Assignee: Kelvin R. Lawrence >Priority: Major > Fix For: 3.5.0 > > > Currently there is no equivalent to GroovyTranslator for the Gremlin Python > client. There is one in the JavaScript client however. Adding one for the > Python client will further help in moving all the clients to a consistent > level of functionality. I have this mostly coded up and will try to submit > some code within the next few days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2527) Add a GroovyTranslator equivalent method to the Python client
[ https://issues.apache.org/jira/browse/TINKERPOP-2527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kelvin R. Lawrence updated TINKERPOP-2527: -- Description: Currently there is no equivalent to GroovyTranslator for the Gremlin Python client. There is one in the JavaScript client however. Adding one for the Python client will further help in moving all the clients to a consistent level of functionality. I have this mostly coded up and will try to submit some code within the next few days. (was: Currently there is no equivalent to GroovyTranslator for the Gremlin Python client. There is one in the JavaScript client however. Adding one for the Python client will further help in moving all he clients to a consistent level of functionality. I have this mostly coded up and will try to submit some code within the next few days.) > Add a GroovyTranslator equivalent method to the Python client > - > > Key: TINKERPOP-2527 > URL: https://issues.apache.org/jira/browse/TINKERPOP-2527 > Project: TinkerPop > Issue Type: Improvement > Components: python >Affects Versions: 3.5.0 >Reporter: Kelvin R. Lawrence >Assignee: Kelvin R. Lawrence >Priority: Major > > Currently there is no equivalent to GroovyTranslator for the Gremlin Python > client. There is one in the JavaScript client however. Adding one for the > Python client will further help in moving all the clients to a consistent > level of functionality. I have this mostly coded up and will try to submit > some code within the next few days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2527) Add a GroovyTranslator equivalent method to the Python client
Kelvin R. Lawrence created TINKERPOP-2527: - Summary: Add a GroovyTranslator equivalent method to the Python client Key: TINKERPOP-2527 URL: https://issues.apache.org/jira/browse/TINKERPOP-2527 Project: TinkerPop Issue Type: New Feature Components: python Affects Versions: 3.5.0 Reporter: Kelvin R. Lawrence Assignee: Kelvin R. Lawrence Currently there is no equivalent to GroovyTranslator for the Gremlin Python client. There is one in the JavaScript client however. Adding one for the Python client will further help in moving all he clients to a consistent level of functionality. I have this mostly coded up and will try to submit some code within the next few days. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2379) Consistent defaults and initialization APIs for drivers
[
https://issues.apache.org/jira/browse/TINKERPOP-2379?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17279140#comment-17279140
]
Kelvin R. Lawrence commented on TINKERPOP-2379:
---
Related to driver defaults/initialization consistency:
The Python client does not specify a default max content length. It inherits
whatever Tornado defaults to (10mb in 4.5.3 for example). However, if Kerberos
is used, the code in the client hard codes 65536 into the web socket frame
header bits in that specific case. This will lead to different behavior and
potentially unexpected frame size exceeded errors errors. We should really have
consistent defaults across all the clients.
There is a separate Jira open to add the ability in the Python client for the
user to override the max content length. No such feature exists today.
> Consistent defaults and initialization APIs for drivers
> ---
>
> Key: TINKERPOP-2379
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2379
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver
>Affects Versions: 3.4.6
>Reporter: Stephen Mallette
>Priority: Minor
>
> Some drivers allow the connection URL to be directly set which means that it
> is wholly configurable. For example, Javascript allows:
> {code}
> const g = traversal().withRemote(new
> DriverRemoteConnection('ws://localhost:8182/gremlin'));
> {code}
> Python allows something similar, but Java and .NET do not. I don't recall a
> reason for that inconsistency and there are times when it seems that such
> options would be helpful.
> In addition, some drivers will take a file for configuration and some will
> not. Furthermore, defaults for various settings are different from one driver
> to the next.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2520) Add the ability to reverse the stream or a collection
Kelvin R. Lawrence created TINKERPOP-2520:
-
Summary: Add the ability to reverse the stream or a collection
Key: TINKERPOP-2520
URL: https://issues.apache.org/jira/browse/TINKERPOP-2520
Project: TinkerPop
Issue Type: New Feature
Reporter: Kelvin R. Lawrence
I had a Gremlin user ask me yesterday if there was a way to have the results of
a `path` step be reversed. Today you cannot do that using `from` and `to` steps
as the `from` label must appear before the `to` label in a path. In thinking
about this, perhaps adding a `reverse` option to order (on top of `asc`,`desc`
and `shuffle`) would be a nice addition to Gremlin. So you could write
something like:
{code:java}
g.V().out().out().path().order(local).by(reverse){code}
For this specific user they were union-ing a set of paths in different
directions and wanted to normalize them to all be in the same direction when
presented as results.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2487) Add steps to support basic analysis like standard deviation and percentile
[
https://issues.apache.org/jira/browse/TINKERPOP-2487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17246736#comment-17246736
]
Kelvin R. Lawrence commented on TINKERPOP-2487:
---
I have recently had two different users ask me if we have considered a
`product` step also that would multiply all the values in the stream together.
There is no easy workaround today outside of using lambdas/closures.
> Add steps to support basic analysis like standard deviation and percentile
> --
>
> Key: TINKERPOP-2487
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2487
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.8
>Reporter: Guo Junshi
>Priority: Minor
>
> When using tinkerpop Gremlin for real use cases, we found that some general
> analytical steps are very useful, yet not supported now. Some analytical
> steps are general enough to be part of the official gremlin package, e.g.
> steps to calculate standard deviation and percentile. The example usage might
> be:
>
> {code:java}
> gremlin> g.V().values('ages')
> ==>1
> ==>2
> ==>3
> gremlin> g.V().values('ages').stdev()
> ==>0.816
> gremlin> g.V().values('ages').fold().stdev(Scope.local)
> ==>0.816
> gremlin> g.V().values('ages').percentile(50)
> ==>2
> // one percentile, return single value
> gremlin> g.V().values('ages').percentile(0, 100)
> ==>[0: 1, 100: 3]
> // multiple percentiles, return a map{code}
> These steps are frequently used in our cases, and we think it would be great
> to support them in official versions.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2478) Console byte code translator has issues with "new Date()"
Kelvin R. Lawrence created TINKERPOP-2478:
-
Summary: Console byte code translator has issues with "new Date()"
Key: TINKERPOP-2478
URL: https://issues.apache.org/jira/browse/TINKERPOP-2478
Project: TinkerPop
Issue Type: Bug
Components: console
Affects Versions: 3.4.8
Environment: Gremlin Console on Mac OS with TinkerGraph
Reporter: Kelvin R. Lawrence
Attempting to do the following results in an error:
{code:java}
gremlin> :bc from g.addV().property('date',new Date())
No signature of method: groovysh_evaluate.newDate() is applicable for argument
types: () values: [] {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2457) Add a max_content_length parameter to DriverRemoteConnection in the Python client
Kelvin R. Lawrence created TINKERPOP-2457:
-
Summary: Add a max_content_length parameter to
DriverRemoteConnection in the Python client
Key: TINKERPOP-2457
URL: https://issues.apache.org/jira/browse/TINKERPOP-2457
Project: TinkerPop
Issue Type: Improvement
Reporter: Kelvin R. Lawrence
I was recently trying to retrieve a subgraph (basically just the air-routes
part of the air-routes data set) using Gremlin Python over Web Sockets. My
query kept failing. After some investigation I discovered that the default
maximum result set for Tornado is 10*1024*1024 (10 gig)
The current Python client does not offer a way to override this from an
application. I would like to propose that we add a `max_content_length`
parameter to the constructor for DriverRemoteConnection so that one could do
something like:
{code:java}
connection = DriverRemoteConnection(
endpoint,
'g',
max_content_length=1024 ** 3){code}
I coded up a prototype for this and it seems to work well. I did not
investigate if we need to also provide such a setting when connecting via HTTP
yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2382) Review and improve driver API for Python
[
https://issues.apache.org/jira/browse/TINKERPOP-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17218355#comment-17218355
]
Kelvin R. Lawrence commented on TINKERPOP-2382:
---
It might be nice to think about allowing options to DriverRemoteConnection via
a **kwargs dict. So for example one might do:
{code:java}
options = {'pool_size' :4, 'max_workers': 4}
connection = DriverRemoteConnection(
endpoint,
'g',
options)
{code}
> Review and improve driver API for Python
>
>
> Key: TINKERPOP-2382
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2382
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.5.0
>Reporter: Stephen Mallette
>Priority: Major
>
> We continually added to the driver API for python without much thought as to
> how it is structured. For example, we recently added kerberos support by just
> adding another keyword argument:
> https://github.com/apache/tinkerpop/pull/1290/files#diff-7221fd838d81694769a9fc4f35d3053eR32
> It would be nice to look at the ever expanding list of keywords there and
> improve/streamline the API a bit while we have a chance at breaking change
> for 3.5.0.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (TINKERPOP-2414) Dynamic options for all steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190291#comment-17190291
]
Kelvin R. Lawrence edited comment on TINKERPOP-2414 at 9/3/20, 6:53 PM:
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
Another common example involves {{hasId}}. People expect this to work
{{g.inject(3L).as('x').V().hasId(select('x'))}}
Where you need to do something like
{{g.inject(3L).as('x').V().where(id().as('x'))}}
was (Author: gfxman):
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
Another common example involves \{{hasId. }}People expect this to work
{{g.inject(3L).as('x').V().hasId(select('x'))}}
Where you need to do something like
{{g.inject(3L).as('x').V().where(id().as('x'))}}
> Dynamic options for all steps
> -
>
> Key: TINKERPOP-2414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2414
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.8
>Reporter: Stephen Mallette
>Priority: Major
>
> This issue may be discussed on a separate ticket somewhere already because I
> feel like it has come up before, but I can't find it immediately. Some steps
> can base their arguments on the result of `Traversal` and some cannot. This
> leads to folks trying things like:
> {code}
> g.V().hasLabel('Person').sample(math('4/2'))
> {code}
> and getting an error. Obviously the above is bit of a contrived example but
> one could imagine modifying the sample size based on some data dynamically
> gathered in the traversal itself. We could proliferate {{Traversal}}
> overloads everywhere for all steps and make it a rule that they should work
> that way or perhaps there is a more elegant approach that hasn't been
> considered yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (TINKERPOP-2414) Dynamic options for all steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190291#comment-17190291
]
Kelvin R. Lawrence edited comment on TINKERPOP-2414 at 9/3/20, 6:28 PM:
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
Another common example involves \{{hasId. }}People expect this to work
{{g.inject(3L).as('x').V().hasId(select('x'))}}
Where you need to do something like
{{g.inject(3L).as('x').V().where(id().as('x'))}}
was (Author: gfxman):
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
Another common example involves {{hasId. }}People expect this to work
{{g.inject(3L).as('x').V().hasId(select('x'))}}
Where you need to do something like
{{ g.inject(3L).as('x').V().where(id().as('x')) }}
> Dynamic options for all steps
> -
>
> Key: TINKERPOP-2414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2414
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.8
>Reporter: Stephen Mallette
>Priority: Major
>
> This issue may be discussed on a separate ticket somewhere already because I
> feel like it has come up before, but I can't find it immediately. Some steps
> can base their arguments on the result of `Traversal` and some cannot. This
> leads to folks trying things like:
> {code}
> g.V().hasLabel('Person').sample(math('4/2'))
> {code}
> and getting an error. Obviously the above is bit of a contrived example but
> one could imagine modifying the sample size based on some data dynamically
> gathered in the traversal itself. We could proliferate {{Traversal}}
> overloads everywhere for all steps and make it a rule that they should work
> that way or perhaps there is a more elegant approach that hasn't been
> considered yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (TINKERPOP-2414) Dynamic options for all steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190291#comment-17190291
]
Kelvin R. Lawrence edited comment on TINKERPOP-2414 at 9/3/20, 6:27 PM:
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
Another common example involves {{hasId. }}People expect this to work
{{g.inject(3L).as('x').V().hasId(select('x'))}}
Where you need to do something like
{{ g.inject(3L).as('x').V().where(id().as('x')) }}
was (Author: gfxman):
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
> Dynamic options for all steps
> -
>
> Key: TINKERPOP-2414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2414
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.8
>Reporter: Stephen Mallette
>Priority: Major
>
> This issue may be discussed on a separate ticket somewhere already because I
> feel like it has come up before, but I can't find it immediately. Some steps
> can base their arguments on the result of `Traversal` and some cannot. This
> leads to folks trying things like:
> {code}
> g.V().hasLabel('Person').sample(math('4/2'))
> {code}
> and getting an error. Obviously the above is bit of a contrived example but
> one could imagine modifying the sample size based on some data dynamically
> gathered in the traversal itself. We could proliferate {{Traversal}}
> overloads everywhere for all steps and make it a rule that they should work
> that way or perhaps there is a more elegant approach that hasn't been
> considered yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2414) Dynamic options for all steps
[
https://issues.apache.org/jira/browse/TINKERPOP-2414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17190291#comment-17190291
]
Kelvin R. Lawrence commented on TINKERPOP-2414:
---
This is timely as I have been also thinking about this and meaning to create an
issue for some time.
I think there is definite confusion about where the result of a traversal can
be used as a parameter. The case that I see most users hit is with the {{has}}
step. If you want to test two properties on the same vertex you have to know
about using {{where...by}} when it feels like {{g.V().has('a',gt(values('b'))
should work}}
Also I see people try people try
{{g.V().has('x',out().count())}}
> Dynamic options for all steps
> -
>
> Key: TINKERPOP-2414
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2414
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.8
>Reporter: Stephen Mallette
>Priority: Major
>
> This issue may be discussed on a separate ticket somewhere already because I
> feel like it has come up before, but I can't find it immediately. Some steps
> can base their arguments on the result of `Traversal` and some cannot. This
> leads to folks trying things like:
> {code}
> g.V().hasLabel('Person').sample(math('4/2'))
> {code}
> and getting an error. Obviously the above is bit of a contrived example but
> one could imagine modifying the sample size based on some data dynamically
> gathered in the traversal itself. We could proliferate {{Traversal}}
> overloads everywhere for all steps and make it a rule that they should work
> that way or perhaps there is a more elegant approach that hasn't been
> considered yet.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2397) Don't create the default Gyro serializer if the caller specifies a different one
Kelvin R. Lawrence created TINKERPOP-2397: - Summary: Don't create the default Gyro serializer if the caller specifies a different one Key: TINKERPOP-2397 URL: https://issues.apache.org/jira/browse/TINKERPOP-2397 Project: TinkerPop Issue Type: Improvement Affects Versions: 3.4.7 Environment: Gremlin Java client at the 3.4.7 level running on Linux using AWS Lambda and also measured using a generic Linux machine. Reporter: Kelvin R. Lawrence In serverless environments such as AWS Lambda, the startup time of the Gremlin client becomes important. This is especially so when the serverless container is "cold". I have been getting fairly regular end user feedback on this so we started doing some analysis. There are many contributing factors but one thing that we could (and I think should) fix is the fact that the Gremlin Java client always creates a Gyro (default) serializer even if a different one such as GraphBinary is specified. To create the unused Gyro serializer adds almost a full second to the cold start time for the Gremlin client on a typical serverless container host. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (TINKERPOP-2384) Inject and withSideEffect causing different outcomes in order step
Kelvin R. Lawrence created TINKERPOP-2384:
-
Summary: Inject and withSideEffect causing different outcomes in
order step
Key: TINKERPOP-2384
URL: https://issues.apache.org/jira/browse/TINKERPOP-2384
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.4.6
Environment: TinkerGraph @ 3.4.6 , TinkerFactory.createModern() ,
Gremlin Console
Reporter: Kelvin R. Lawrence
I tried creating the following query two different ways. One using _*inject*_
and the other using _*withSideEffect*_. The version using _*inject*_ works as
expected and the version using _*withSideEffect*_ causes an exception. As I
understand it, in this case the two should be equivalent. When used outside of
an *_order().by()_* the _*select*_ steps work fine in my testing
gremlin>
g.inject('name').as('key').V().order().by(valueMap().select(select('key')).unfold()).values('name')
==>josh
==>lop
==>marko
==>peter
==>ripple
==>vadas
gremlin>
g.withSideEffect('key','name').V().order().by(valueMap().select(select('key')).unfold()).values('name')
The provided traverser does not map to a value: v[1]->[PropertyMapStep(value),
TraversalSelectStep([SelectOneStep(last,ke
y)]), UnfoldStep]
Type ':help' or ':h' for help.
gremlin>
g.withSideEffect('key','name').V().valueMap().select(select('key')).unfold()
==>marko
==>vadas
==>lop
==>josh
==>ripple
==>peter
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (TINKERPOP-2375) Text Predicates fail if they encounter non strings
[
https://issues.apache.org/jira/browse/TINKERPOP-2375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin R. Lawrence updated TINKERPOP-2375:
--
Description:
This issue comes from investigating the report on Stack Overflow here:
[https://stackoverflow.com/questions/62013568/how-to-do-gremlin-contain-search-for-both-number-and-string]
It was reported against Neptune but I see the same behavior with TinkerGraph.
As best I can tell the poster has overloaded a property key so that it is
sometimes a float and sometimes a string. There is no error if the number
matches exactly but if it does not and the TextP part of the {{or}} step
triggers then an exception is thrown as {{TextP.containing}} tries to work
against a float value. I guess the question is, should the text predicates be
smart enough to ignore non String property values?
Here is a simple reproducer
{{}}
{code:java}
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV('test').property('x',12.5)
==>v[0]
gremlin> g.addV('test').property('x','ABCDEF')
==>v[2]
gremlin>
g.V().hasLabel('test').or(has('x',12.3),has('x',TextP.containing('CDE')))
java.math.BigDecimal cannot be cast to java.lang.String
Type ':help' or ':h' for help.
Display stack trace? [yN] {code}
{{}}
was:
This issue comes from investigating the report on Stack Overflow here:
[https://stackoverflow.com/questions/62013568/how-to-do-gremlin-contain-search-for-both-number-and-string]
It was reported against Neptune but I see the same behavior with TinkerGraph.
As best I can tell the poster has overloaded a property key so that it is
sometimes a float and sometimes a string. There is no error if the number
matches exactly but if it does not and the TextP part of the {{or}} step
triggers then an exception is thrown as {{TextP.containing}} tries to work
against a float value. I guess the question is, should the text predicates be
smart enough to ignore non String property values?
Here is a simple reproducer
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV('test').property('x',12.5)
==>v[0]
gremlin> g.addV('test').property('x','ABCDEF')
==>v[2]
gremlin>
g.V().hasLabel('test').or(has('x',12.3),has('x',TextP.containing('CDE')))
java.math.BigDecimal cannot be cast to java.lang.String
Type ':help' or ':h' for help.
Display stack trace? [yN]
> Text Predicates fail if they encounter non strings
> --
>
> Key: TINKERPOP-2375
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2375
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.6
> Environment: MacOS + TinkerPop 3.4.6 , Gremlin Console, TinkerGraph
>Reporter: Kelvin R. Lawrence
>Priority: Minor
>
> This issue comes from investigating the report on Stack Overflow here:
> [https://stackoverflow.com/questions/62013568/how-to-do-gremlin-contain-search-for-both-number-and-string]
> It was reported against Neptune but I see the same behavior with TinkerGraph.
> As best I can tell the poster has overloaded a property key so that it is
> sometimes a float and sometimes a string. There is no error if the number
> matches exactly but if it does not and the TextP part of the {{or}} step
> triggers then an exception is thrown as {{TextP.containing}} tries to work
> against a float value. I guess the question is, should the text predicates be
> smart enough to ignore non String property values?
> Here is a simple reproducer
> {{}}
> {code:java}
> gremlin> graph = TinkerGraph.open()
> ==>tinkergraph[vertices:0 edges:0]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> gremlin> g.addV('test').property('x',12.5)
> ==>v[0]
> gremlin> g.addV('test').property('x','ABCDEF')
> ==>v[2]
> gremlin>
> g.V().hasLabel('test').or(has('x',12.3),has('x',TextP.containing('CDE')))
> java.math.BigDecimal cannot be cast to java.lang.String
> Type ':help' or ':h' for help.
> Display stack trace? [yN] {code}
> {{}}
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2375) Text Predicates fail if they encounter non strings
Kelvin R. Lawrence created TINKERPOP-2375:
-
Summary: Text Predicates fail if they encounter non strings
Key: TINKERPOP-2375
URL: https://issues.apache.org/jira/browse/TINKERPOP-2375
Project: TinkerPop
Issue Type: Bug
Components: process
Affects Versions: 3.4.6
Environment: MacOS + TinkerPop 3.4.6 , Gremlin Console, TinkerGraph
Reporter: Kelvin R. Lawrence
This issue comes from investigating the report on Stack Overflow here:
[https://stackoverflow.com/questions/62013568/how-to-do-gremlin-contain-search-for-both-number-and-string]
It was reported against Neptune but I see the same behavior with TinkerGraph.
As best I can tell the poster has overloaded a property key so that it is
sometimes a float and sometimes a string. There is no error if the number
matches exactly but if it does not and the TextP part of the {{or}} step
triggers then an exception is thrown as {{TextP.containing}} tries to work
against a float value. I guess the question is, should the text predicates be
smart enough to ignore non String property values?
Here is a simple reproducer
gremlin> graph = TinkerGraph.open()
==>tinkergraph[vertices:0 edges:0]
gremlin> g = graph.traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV('test').property('x',12.5)
==>v[0]
gremlin> g.addV('test').property('x','ABCDEF')
==>v[2]
gremlin>
g.V().hasLabel('test').or(has('x',12.3),has('x',TextP.containing('CDE')))
java.math.BigDecimal cannot be cast to java.lang.String
Type ':help' or ':h' for help.
Display stack trace? [yN]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2296) Per query timeout not working from Python
[
https://issues.apache.org/jira/browse/TINKERPOP-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17093607#comment-17093607
]
Kelvin R. Lawrence commented on TINKERPOP-2296:
---
In the near term I think for a lot of (most?) users the simple fix of having
the Python client do what the Java client does and pull the timeout out of the
traversal and add it to the Request payload would be fine. I get asked for this
by Python users quite a lot and I think that would meet their needs.
> Per query timeout not working from Python
> -
>
> Key: TINKERPOP-2296
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2296
> Project: TinkerPop
> Issue Type: Bug
> Components: python, server
>Affects Versions: 3.4.3
> Environment: Gremlin Server 3.4.3 and GremlinPython latest
>Reporter: Kelvin R. Lawrence
>Priority: Major
>
> I had a discussion with [~spmallette] about some problems I have been running
> into trying to get per query timeouts to work using the Python GLV client. As
> best as I can tell the timeout setting just gets ignored. The query executes
> to completion taking as many seconds as needed. Stephen asked for a Jira so
> writing this up here.
> Using the air-routes data set this query can take a few seconds so should
> definitely time out at 200ms. Using the Java client the same query works
> although I had an exception when using the Binary serializer but it worked
> when using GraphSON. I don't know yet if that is relevant to this issue.
>
> {{paths = (g.V().with_('scriptEvaluationTimeout', 200).}}
> {{ has('airport', 'code', 'AUS').}}
> {{ repeat(__.out('route').simplePath()).}}
> {{ until(__.has('code', 'AGR')).}}
> {{ path().by('code').}}
> {{ limit(10).}}
> {{ toList())}}
>
> {{As a sidenote it would be nice if the Python client had an equivalent of
> the Java Tokens class so that constant variable names rather than strings
> could be used for the 'scriptEvaluationTimeout' part.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2306) TextP operator containing not work on java core driver
[
https://issues.apache.org/jira/browse/TINKERPOP-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954894#comment-16954894
]
Kelvin R. Lawrence commented on TINKERPOP-2306:
---
Are you submitting your query as Bytecode or using submit() ?
> TextP operator containing not work on java core driver
> --
>
> Key: TINKERPOP-2306
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2306
> Project: TinkerPop
> Issue Type: Bug
> Components: driver
>Affects Versions: 3.4.0, 3.4.1
>Reporter: Kalawa André
>Priority: Major
>
> I am using gremlin driver for java (3.4.0 version).
> My remote database is Neptune AWS, this version supporte containing operator.
> But through the gremlin driver in my java code I am getting an exception for
> the operator
> _TextP.containing._
> _Here are some details_
> {code:java}
> // my gremlin query
> 1) ok case
> g.V().hasLabel('toons').repeat(out().simplePath()).until(has('denomination',
> 'Name', P.eq('Asterix')))
> 2 ko case
> g.V().hasLabel('toons').repeat(out().simplePath()).until(has('denomination',
> 'Name', TextP.containing('Asterix')))
> // Exceptions from Neptune
> REQUEST_ERROR_INVALID_REQUEST_ARGUMENTS
> {"code":"InvalidParameterException","detailedMessage":"Invalid OpProcessor
> requested [null]"}
> // Exception from Driver
> java.lang.NullPointerException: null
> {code}
> I found same issue here
> [https://github.com/JanusGraph/janusgraph/issues/239]
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2296) Per query timeout not working from Python
[
https://issues.apache.org/jira/browse/TINKERPOP-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16946961#comment-16946961
]
Kelvin R. Lawrence commented on TINKERPOP-2296:
---
Thanks for the clarification Stephen. Very helpful. It would definitely be nice
for the GLV clients to get closer in parity to the Java one. Things like per
query timeout being an especially useful feature to have from any client. I
believe the same applies to things like user provided query IDs.
> Per query timeout not working from Python
> -
>
> Key: TINKERPOP-2296
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2296
> Project: TinkerPop
> Issue Type: Bug
> Components: python, server
>Affects Versions: 3.4.3
> Environment: Gremlin Server 3.4.3 and GremlinPython latest
>Reporter: Kelvin R. Lawrence
>Priority: Major
>
> I had a discussion with [~spmallette] about some problems I have been running
> into trying to get per query timeouts to work using the Python GLV client. As
> best as I can tell the timeout setting just gets ignored. The query executes
> to completion taking as many seconds as needed. Stephen asked for a Jira so
> writing this up here.
> Using the air-routes data set this query can take a few seconds so should
> definitely time out at 200ms. Using the Java client the same query works
> although I had an exception when using the Binary serializer but it worked
> when using GraphSON. I don't know yet if that is relevant to this issue.
>
> {{paths = (g.V().with_('scriptEvaluationTimeout', 200).}}
> {{ has('airport', 'code', 'AUS').}}
> {{ repeat(__.out('route').simplePath()).}}
> {{ until(__.has('code', 'AGR')).}}
> {{ path().by('code').}}
> {{ limit(10).}}
> {{ toList())}}
>
> {{As a sidenote it would be nice if the Python client had an equivalent of
> the Java Tokens class so that constant variable names rather than strings
> could be used for the 'scriptEvaluationTimeout' part.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2296) Per query timeout not working from Python
[
https://issues.apache.org/jira/browse/TINKERPOP-2296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944830#comment-16944830
]
Kelvin R. Lawrence commented on TINKERPOP-2296:
---
I may be missing a nuance [~spmallette] but why does it work using the Java
client? Is the Java client doing something special in this case?
> Per query timeout not working from Python
> -
>
> Key: TINKERPOP-2296
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2296
> Project: TinkerPop
> Issue Type: Bug
> Components: python, server
>Affects Versions: 3.4.3
> Environment: Gremlin Server 3.4.3 and GremlinPython latest
>Reporter: Kelvin R. Lawrence
>Priority: Major
>
> I had a discussion with [~spmallette] about some problems I have been running
> into trying to get per query timeouts to work using the Python GLV client. As
> best as I can tell the timeout setting just gets ignored. The query executes
> to completion taking as many seconds as needed. Stephen asked for a Jira so
> writing this up here.
> Using the air-routes data set this query can take a few seconds so should
> definitely time out at 200ms. Using the Java client the same query works
> although I had an exception when using the Binary serializer but it worked
> when using GraphSON. I don't know yet if that is relevant to this issue.
>
> {{paths = (g.V().with_('scriptEvaluationTimeout', 200).}}
> {{ has('airport', 'code', 'AUS').}}
> {{ repeat(__.out('route').simplePath()).}}
> {{ until(__.has('code', 'AGR')).}}
> {{ path().by('code').}}
> {{ limit(10).}}
> {{ toList())}}
>
> {{As a sidenote it would be nice if the Python client had an equivalent of
> the Java Tokens class so that constant variable names rather than strings
> could be used for the 'scriptEvaluationTimeout' part.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (TINKERPOP-2296) Per query timeout not working from Python
Kelvin R. Lawrence created TINKERPOP-2296:
-
Summary: Per query timeout not working from Python
Key: TINKERPOP-2296
URL: https://issues.apache.org/jira/browse/TINKERPOP-2296
Project: TinkerPop
Issue Type: Bug
Components: python, server
Affects Versions: 3.4.3
Environment: Gremlin Server 3.4.3 and GremlinPython latest
Reporter: Kelvin R. Lawrence
I had a discussion with [~spmallette] about some problems I have been running
into trying to get per query timeouts to work using the Python GLV client. As
best as I can tell the timeout setting just gets ignored. The query executes to
completion taking as many seconds as needed. Stephen asked for a Jira so
writing this up here.
Using the air-routes data set this query can take a few seconds so should
definitely time out at 200ms. Using the Java client the same query works
although I had an exception when using the Binary serializer but it worked when
using GraphSON. I don't know yet if that is relevant to this issue.
{{paths = (g.V().with_('scriptEvaluationTimeout', 200).}}
{{ has('airport', 'code', 'AUS').}}
{{ repeat(__.out('route').simplePath()).}}
{{ until(__.has('code', 'AGR')).}}
{{ path().by('code').}}
{{ limit(10).}}
{{ toList())}}
{{As a sidenote it would be nice if the Python client had an equivalent of the
Java Tokens class so that constant variable names rather than strings could be
used for the 'scriptEvaluationTimeout' part.}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (TINKERPOP-2272) Rename steps and tokens that conflict with standard python functions
[
https://issues.apache.org/jira/browse/TINKERPOP-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16893225#comment-16893225
]
Kelvin R. Lawrence commented on TINKERPOP-2272:
---
VOTE +1
> Rename steps and tokens that conflict with standard python functions
>
>
> Key: TINKERPOP-2272
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2272
> Project: TinkerPop
> Issue Type: Improvement
> Components: python
>Affects Versions: 3.3.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
>
> The following steps overlap standard python functions:
> {code}
> filter()
> id()
> max()
> min()
> range()
> sum()
> {code}
> They need to be renamed to have the underscore suffix.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Created] (TINKERPOP-2188) PartitionStrategy from Python causes a 599 GremlinServer error
Kelvin R. Lawrence created TINKERPOP-2188:
-
Summary: PartitionStrategy from Python causes a 599 GremlinServer
error
Key: TINKERPOP-2188
URL: https://issues.apache.org/jira/browse/TINKERPOP-2188
Project: TinkerPop
Issue Type: Bug
Components: python
Affects Versions: 3.4.1
Environment: Linux client, Python 3, pip install of gremlinpython 3.4.1
Reporter: Kelvin R. Lawrence
Using the code snippet below to any GremlinServer running even an empty
TinkerGraph causes GremlinServer to fail with a 599 error. I assume as this is
a decoration strategy that the client side Python is generating something
invalid. I could not find any coverage for PartitionStrategy in the strategy
test cases for the Python client. Maybe I missed them but did not find any. I
opened this against 3.4.1 but I have not tried to use this strategy from Python
before so not sure if it worked previously.
{code:java}
from gremlin_python.driver.driver_remote_connection import
DriverRemoteConnection
from gremlin_python.structure.graph import Graph
from gremlin_python import statics
from gremlin_python.process.graph_traversal import __
from gremlin_python.process.strategies import *
from gremlin_python.process.traversal import *
from gremlin_python.process.anonymous_traversal import traversal
import sys
endpoint = 'ws://localhost:8182/gremlin'
graph=Graph()
connection = DriverRemoteConnection(endpoint,'g')
g = traversal().withRemote(connection)
g2 =
g.withStrategies(PartitionStrategy(partition_key="partition",write_partition="a",
read_partitions="a"))
try:
x = g2.addV('test').property("p1",1).toList()
except:
print("Exception trying to add a vertex")
print(sys.exc_info())
finally:
connection.close(){code}
When run the code above will generate this error:
{code:java}
Exception trying to add a vertex
(,
GremlinServerError('599: None',), )
connection.close(){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2172) PartitionStrategy doesn't apply to AddEdgeStartStep
[
https://issues.apache.org/jira/browse/TINKERPOP-2172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16805326#comment-16805326
]
Kelvin R. Lawrence commented on TINKERPOP-2172:
---
I'm not quite sure from the fix version and reported version above. Did this
fix make the 3.4.1 release? It still seems to be failing at that level for me.
Cheers, Kelvin.
> PartitionStrategy doesn't apply to AddEdgeStartStep
> ---
>
> Key: TINKERPOP-2172
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2172
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.4.1
>Reporter: Vladimir
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> PartitionStrategy doesn't apply to traversal started with addE step.
> For instance:
> PartitionStrategy partitionStrategy = PartitionStrategy.build()
>
> .partitionKey({color:#660e7a}partition{color}).writePartition({color:#008000}"A"{color}).readPartitions({color:#008000}"A"{color}).create();
> GraphTraversalSource source =
> {color:#660e7a}g{color}.withStrategies(partitionStrategy);
> Vertex v1 = source.addV().property({color:#008000}"any"{color},
> {color:#008000}"thing"{color}).next();
> Vertex v2 = source.addV().property({color:#008000}"some"{color},
> {color:#008000}"thing"{color}).next();
> Edge e1 = source.withSideEffect({color:#008000}"v2"{color},
> v2).V(v1.id()).addE({color:#008000}"connectsTo"{color}).from({color:#008000}"v2"{color}).property({color:#008000}"every"{color},
> {color:#008000}"thing"{color}).next();
> Edge e2 =
> source.addE({color:#008000}"relatesTo"{color}).from(v2).to(v1).property({color:#008000}"every"{color},
> {color:#008000}"thing"{color}).next();
> If you check e1 you will see partition property. But edge e2 wont have any
> partition property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2098) gremlin-server.sh start does not seem to work as advertised
[
https://issues.apache.org/jira/browse/TINKERPOP-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16696308#comment-16696308
]
Kelvin R. Lawrence commented on TINKERPOP-2098:
---
If it’s working as designed I think a good enhancement would be for start to
support a yaml file being specified as the script’s help text makes no mention
of the environment variable. Alternatively I suggest adding mention of the
environment variables to the help text.
> gremlin-server.sh start does not seem to work as advertised
> ---
>
> Key: TINKERPOP-2098
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2098
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.4
>Reporter: Kelvin R. Lawrence
>Priority: Minor
>
> This may be as simple as a documentation issue but the help text for Gremlin
> server implies that I should be able to do:
> {code:java}
> gremlin-server.sh start conf/myyaml.yaml{code}
> However when I do that it does not seem to actually be reading my YAML file
> or if it is it is not reading it fully as I am specifying the WsAndHttp
> channelizer in the YAML and when the server starts the HTTP endpoint is not
> available.
>
> If I start the server in the terminal with
>
> {code:java}
> gremlin-server.sh conf/myyaml.yaml{code}
>
> all is fine but I want to start it in the background.
>
> I spoke to [~pluradj] and he had me try using the environment variable to
> specify the YAML file name and that worked with the *start* keyword.
>
> Is *gremlin-server.sh start conf/myyaml.yam*l supposed to work?
>
> If not it would be good to change the help text for gremlin-server.sh which
> currently reads as follows:
>
>
> {code:java}
> Usage: bin/gremlin-server.sh {start|stop|restart|status|console|install
> |}{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (TINKERPOP-2098) gremlin-server.sh start does not seem to work as advertised
[
https://issues.apache.org/jira/browse/TINKERPOP-2098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kelvin R. Lawrence updated TINKERPOP-2098:
--
Description:
This may be as simple as a documentation issue but the help text for Gremlin
server implies that I should be able to do:
{code:java}
gremlin-server.sh start conf/myyaml.yaml{code}
However when I do that it does not seem to actually be reading my YAML file or
if it is it is not reading it fully as I am specifying the WsAndHttp
channelizer in the YAML and when the server starts the HTTP endpoint is not
available.
If I start the server in the terminal with
{code:java}
gremlin-server.sh conf/myyaml.yaml{code}
all is fine but I want to start it in the background.
I spoke to [~pluradj] and he had me try using the environment variable to
specify the YAML file name and that worked with the *start* keyword.
Is *gremlin-server.sh start conf/myyaml.yam*l supposed to work?
If not it would be good to change the help text for gremlin-server.sh which
currently reads as follows:
{code:java}
Usage: bin/gremlin-server.sh {start|stop|restart|status|console|install
|}{code}
was:
This may be as simple as a documentation issue but the help text for Gremlin
server implies that I should be able to do:
{code:java}
gremlin-server.sh start conf/myyaml.yam{code}
However when I do that it does not seem to actually be reading my YAML file or
if it is it is not reading it fully as I am specifying the WsAndHttp
channelizer in the YAML and when the server starts the HTTP endpoint is not
available.
If I start the server in the terminal with
{code:java}
gremlin-server.sh conf/myyaml.yaml{code}
all is fine but I want to start it in the background.
I spoke to [~pluradj] and he had me try using the environment variable to
specify the YAML file name and that worked with the *start* keyword.
Is *gremlin-server.sh start conf/myyaml.yam*l supposed to work?
If not it would be good to change the help text for gremlin-server.sh which
currently reads as follows:
{code:java}
Usage: bin/gremlin-server.sh {start|stop|restart|status|console|install
|}{code}
> gremlin-server.sh start does not seem to work as advertised
> ---
>
> Key: TINKERPOP-2098
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2098
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.3.4
>Reporter: Kelvin R. Lawrence
>Priority: Minor
>
> This may be as simple as a documentation issue but the help text for Gremlin
> server implies that I should be able to do:
> {code:java}
> gremlin-server.sh start conf/myyaml.yaml{code}
> However when I do that it does not seem to actually be reading my YAML file
> or if it is it is not reading it fully as I am specifying the WsAndHttp
> channelizer in the YAML and when the server starts the HTTP endpoint is not
> available.
>
> If I start the server in the terminal with
>
> {code:java}
> gremlin-server.sh conf/myyaml.yaml{code}
>
> all is fine but I want to start it in the background.
>
> I spoke to [~pluradj] and he had me try using the environment variable to
> specify the YAML file name and that worked with the *start* keyword.
>
> Is *gremlin-server.sh start conf/myyaml.yam*l supposed to work?
>
> If not it would be good to change the help text for gremlin-server.sh which
> currently reads as follows:
>
>
> {code:java}
> Usage: bin/gremlin-server.sh {start|stop|restart|status|console|install
> |}{code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (TINKERPOP-2098) gremlin-server.sh start does not seem to work as advertised
Kelvin R. Lawrence created TINKERPOP-2098:
-
Summary: gremlin-server.sh start does not seem to work as
advertised
Key: TINKERPOP-2098
URL: https://issues.apache.org/jira/browse/TINKERPOP-2098
Project: TinkerPop
Issue Type: Improvement
Components: server
Affects Versions: 3.3.4
Reporter: Kelvin R. Lawrence
This may be as simple as a documentation issue but the help text for Gremlin
server implies that I should be able to do:
{code:java}
gremlin-server.sh start conf/myyaml.yam{code}
However when I do that it does not seem to actually be reading my YAML file or
if it is it is not reading it fully as I am specifying the WsAndHttp
channelizer in the YAML and when the server starts the HTTP endpoint is not
available.
If I start the server in the terminal with
{code:java}
gremlin-server.sh conf/myyaml.yaml{code}
all is fine but I want to start it in the background.
I spoke to [~pluradj] and he had me try using the environment variable to
specify the YAML file name and that worked with the *start* keyword.
Is *gremlin-server.sh start conf/myyaml.yam*l supposed to work?
If not it would be good to change the help text for gremlin-server.sh which
currently reads as follows:
{code:java}
Usage: bin/gremlin-server.sh {start|stop|restart|status|console|install
|}{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-2041) Text Predicates
[
https://issues.apache.org/jira/browse/TINKERPOP-2041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16626067#comment-16626067
]
Kelvin R. Lawrence commented on TINKERPOP-2041:
---
Thanks for opening this issue Daniel. As I talk to Graph DB users I am more and
more hearing a request for TinkerPop to "standardize" some number of text
search predicates. I think it will be really good to have some level of text
search support that is guaranteed to work across all DBs that implement the
TinkerPop API.
> Text Predicates
> ---
>
> Key: TINKERPOP-2041
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2041
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.4.0
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Provide these simple text predicates:
> * {{startsWith}}
> * {{endsWith}}
> * {{contains}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
