[jira] [Created] (TINKERPOP-3048) Class is not working right in language variants
Stephen Mallette created TINKERPOP-3048:
---
Summary: Class is not working right in language variants
Key: TINKERPOP-3048
URL: https://issues.apache.org/jira/browse/TINKERPOP-3048
Project: TinkerPop
Issue Type: Bug
Components: dotnet, go, javascript, python
Affects Versions: 3.7.1
Reporter: Stephen Mallette
{{withoutStrategies()}} takes {{Class}} but the GLVs all have their own
problems with this. it's typically one of several problems:
1. bad method signature using {{TraversalStrategy}} rather than {{Class}}.
2. the translators are broken in some way
3. the serializers are broken for serializing {{Class}}
Need to get this fixed so that TINKERPOP-2862 can be settled.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (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 ] Cole Greer closed TINKERPOP-2995. - Fix Version/s: 3.6.7 3.7.2 Assignee: Cole Greer Resolution: Fixed > 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 >Assignee: Cole Greer >Priority: Major > Fix For: 3.6.7, 3.7.2 > > > 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-3020) Incorrect tests
[
https://issues.apache.org/jira/browse/TINKERPOP-3020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-3020:
Issue Type: Improvement (was: Test)
> Incorrect tests
> ---
>
> Key: TINKERPOP-3020
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3020
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.7.1
>Reporter: pieter martin
>Priority: Major
>
> The following tests are incorrectly specified.
> {code:java}
> OptOut...
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_bothE_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_bothE_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_bothE_dedup_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_bothE_weight",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_both_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_both_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_both_dedup_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_both_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_aXX_V_out_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_bXX_V_in_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_a_bXX_V_out_name",
> "int should be double"),
> Map.entry("g_withStrategiesXPartitionStrategyXwrite_a_read_cXX_V_out_name",
> "int should be double"),
> Map.entry("g_VX1X_formatXstrX_byXconstantXhelloXX_byXvaluesXnameXX", "id can
> not be an int"),
> Map.entry("g_withSideEffectXc_created_YX_withSideEffectXm_matchedX_mergeEXlabel_knows_out_marko_in_vadasX_optionXonCreate_selectXcXX_optionXonMatch_sideEffectXpropertiesXweightX_dropX_selectXmXX_exists",
> "int should be double"),
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3047) Grammar does not parse keywords into Map keys
[
https://issues.apache.org/jira/browse/TINKERPOP-3047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-3047:
Description: {{[keys: ["a","b"]}} won't work because "keys" ends up being
parsed to {{Column.keys}}. another issue at play is the use of parens to wrap
certain key definitions but not others. it doesn't feel consistent. like, it
will work for {{T}} values but not for something like "edges" which is just a
keyword token. Not sure it's wrong but it requires some examination. (was:
{{[keys: ["a","b"]}} won't work because "keys" ends up being parsed to
{{Column.keys}}. )
> Grammar does not parse keywords into Map keys
> -
>
> Key: TINKERPOP-3047
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3047
> Project: TinkerPop
> Issue Type: Bug
> Components: language
>Affects Versions: 3.7.1
>Reporter: Stephen Mallette
>Priority: Critical
>
> {{[keys: ["a","b"]}} won't work because "keys" ends up being parsed to
> {{Column.keys}}. another issue at play is the use of parens to wrap certain
> key definitions but not others. it doesn't feel consistent. like, it will
> work for {{T}} values but not for something like "edges" which is just a
> keyword token. Not sure it's wrong but it requires some examination.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3030) Update to .NET 8
[ https://issues.apache.org/jira/browse/TINKERPOP-3030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813739#comment-17813739 ] ASF GitHub Bot commented on TINKERPOP-3030: --- FlorianHockmann commented on PR #2468: URL: https://github.com/apache/tinkerpop/pull/2468#issuecomment-1924148227 Just to clarify: This PR doesn't change which frameworks we support with Gremlin.Net. It's only about which frameworks we use to build and test it. Gremlin.Net mainly [targets .NET Standard 2.0](https://github.com/apache/tinkerpop/blob/master/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj#L21) which is implemented by various .NET frameworks like .NET 5, .NET 6, .NET 7, and .NET 8. It has .NET 6 as an additional explicit target because we optionally use some APIs which were only introduced in .NET 6 to support Websocket compression. This can therefore only be used by users on .NET 6 and higher. Before this PR, we built and tested Gremlin.Net with .NET 6. With this PR, we're using .NET 8 instead. But users can still stay on .NET 6 (or 7 or whatever) and use newer versions of Gremlin.Net with it. Not sure if this was clear to you and you just wanted to propose that we **test** against .NET 6 **and** .NET 8. In that case, I agree with you in general that it would be good to test on both frameworks (or better to say runtimes in this case). The problem with that however is that all contributors then also need both runtimes installed. If you just have .NET 8 installed, then the tests will fail as you also need .NET 6 in that case. That's also why we always use the same version across all release branches. In the end, the question comes down to how many contributors are actually affected by this and how often do we expect to find version specific bugs because of it. I guess many contributors simply don't execute .NET tests on their machines and leave that up to GH Actions or they use the Docker based setup to execute the tests. So, this probably doesn't affect many contributors. On the other hand, [TINKERPOP-3029](https://issues.apache.org/jira/browse/TINKERPOP-3029) is also the only bug that comes to my mind which we could have catched by executing tests on different runtimes. Although I think it wouldn't have helped much as we still would have to be on .NET 8 in the first place to find it. So, the better question is how often a bug occurs that is specific to an **older** framework than the latest LTS version which we want to use by default. I don't have a strong opinion on this. If we are confident that this doesn't really affect contributors negatively, then I'm in favor of executing the tests on multiple runtimes. Otherwise, I'd stay with our current approach. > Update to .NET 8 > > > Key: TINKERPOP-3030 > URL: https://issues.apache.org/jira/browse/TINKERPOP-3030 > Project: TinkerPop > Issue Type: Improvement > Components: dotnet >Affects Versions: 3.5.8, 3.6.6, 3.7.1 >Reporter: Florian Hockmann >Assignee: Florian Hockmann >Priority: Minor > > .NET 8 is now the latest LTS release so we should update to it. > We need to do that on all release branches so contributors only need to have > one version of .NET installed on their systems. > This also means that we test by default with .NET 8 which would have shown > problems like the one described in TINKERPOP-3029. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (TINKERPOP-3047) Grammar does not parse keywords into Map keys
Stephen Mallette created TINKERPOP-3047:
---
Summary: Grammar does not parse keywords into Map keys
Key: TINKERPOP-3047
URL: https://issues.apache.org/jira/browse/TINKERPOP-3047
Project: TinkerPop
Issue Type: Bug
Components: language
Affects Versions: 3.7.1
Reporter: Stephen Mallette
{{[keys: ["a","b"]}} won't work because "keys" ends up being parsed to
{{Column.keys}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (TINKERPOP-3046) Make new keyword optional in Gremlin grammar
Stephen Mallette created TINKERPOP-3046:
---
Summary: Make new keyword optional in Gremlin grammar
Key: TINKERPOP-3046
URL: https://issues.apache.org/jira/browse/TINKERPOP-3046
Project: TinkerPop
Issue Type: Improvement
Components: language
Affects Versions: 3.7.1
Reporter: Stephen Mallette
The {{new}} keyword doesn't really add anything to Gremlin as a language and it
is used inconsistently. It was originally added because of the use in Java and
Groovy but there really is no need for that. Make it optional for all cases so
that it can ultimately be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3045) EarlyLimitStrategy is too aggresive to promote Limit and thus causing incorrect results
[
https://issues.apache.org/jira/browse/TINKERPOP-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-3045:
Environment: (was: ALL)
> EarlyLimitStrategy is too aggresive to promote Limit and thus causing
> incorrect results
> ---
>
> Key: TINKERPOP-3045
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3045
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.6
>Reporter: Prashant
>Priority: Major
> Labels: easyfix
> Fix For: 3.6.7
>
>
> {code:java}
> gremlin> g.V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko{code}
> {code:java}
> gremlin>
> g.withoutStrategies(EarlyLimitStrategy).V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko
> ==>marko {code}
> Early Limit strategy pulls Limit in front of map steps. However not all map
> steps allow the cardinality of the results flowing to be same.
>
> As is shown in example above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (TINKERPOP-3045) EarlyLimitStrategy is too aggresive to promote Limit and thus causing incorrect results
[
https://issues.apache.org/jira/browse/TINKERPOP-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette updated TINKERPOP-3045:
Flags: (was: Important)
> EarlyLimitStrategy is too aggresive to promote Limit and thus causing
> incorrect results
> ---
>
> Key: TINKERPOP-3045
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3045
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.6
>Reporter: Prashant
>Priority: Major
> Labels: easyfix
> Fix For: 3.6.7
>
>
> {code:java}
> gremlin> g.V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko{code}
> {code:java}
> gremlin>
> g.withoutStrategies(EarlyLimitStrategy).V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko
> ==>marko {code}
> Early Limit strategy pulls Limit in front of map steps. However not all map
> steps allow the cardinality of the results flowing to be same.
>
> As is shown in example above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (TINKERPOP-3045) EarlyLimitStrategy is too aggresive to promote Limit and thus causing incorrect results
[
https://issues.apache.org/jira/browse/TINKERPOP-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stephen Mallette reassigned TINKERPOP-3045:
---
Assignee: Stephen Mallette
> EarlyLimitStrategy is too aggresive to promote Limit and thus causing
> incorrect results
> ---
>
> Key: TINKERPOP-3045
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3045
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.6
>Reporter: Prashant
>Assignee: Stephen Mallette
>Priority: Major
> Labels: easyfix
> Fix For: 3.6.7
>
>
> {code:java}
> gremlin> g.V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko{code}
> {code:java}
> gremlin>
> g.withoutStrategies(EarlyLimitStrategy).V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko
> ==>marko {code}
> Early Limit strategy pulls Limit in front of map steps. However not all map
> steps allow the cardinality of the results flowing to be same.
>
> As is shown in example above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3045) EarlyLimitStrategy is too aggresive to promote Limit and thus causing incorrect results
[
https://issues.apache.org/jira/browse/TINKERPOP-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813644#comment-17813644
]
ASF GitHub Bot commented on TINKERPOP-3045:
---
spmallette commented on PR #2475:
URL: https://github.com/apache/tinkerpop/pull/2475#issuecomment-1923659468
for other committers, i will help backfill some extra tests on this one,
deal with CHANGELOG, etc. on merge
> EarlyLimitStrategy is too aggresive to promote Limit and thus causing
> incorrect results
> ---
>
> Key: TINKERPOP-3045
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3045
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.6
> Environment: ALL
>Reporter: Prashant
>Priority: Major
> Labels: easyfix
> Fix For: 3.6.7
>
>
> {code:java}
> gremlin> g.V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko{code}
> {code:java}
> gremlin>
> g.withoutStrategies(EarlyLimitStrategy).V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko
> ==>marko {code}
> Early Limit strategy pulls Limit in front of map steps. However not all map
> steps allow the cardinality of the results flowing to be same.
>
> As is shown in example above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3045) EarlyLimitStrategy is too aggresive to promote Limit and thus causing incorrect results
[
https://issues.apache.org/jira/browse/TINKERPOP-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813632#comment-17813632
]
ASF GitHub Bot commented on TINKERPOP-3045:
---
spmallette commented on code in PR #2475:
URL: https://github.com/apache/tinkerpop/pull/2475#discussion_r1475959035
##
gremlin-core/pom.xml:
##
@@ -101,6 +101,16 @@ limitations under the License.
hamcrest
test
+
Review Comment:
it looks like there is relatively minor usage of guava and lombok. could you
please adjust the `StepOutputArityPredictor` to not use these libraries so
that we don't need to take the dependency?
> EarlyLimitStrategy is too aggresive to promote Limit and thus causing
> incorrect results
> ---
>
> Key: TINKERPOP-3045
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3045
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.6
> Environment: ALL
>Reporter: Prashant
>Priority: Major
> Labels: easyfix
> Fix For: 3.6.7
>
>
> {code:java}
> gremlin> g.V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko{code}
> {code:java}
> gremlin>
> g.withoutStrategies(EarlyLimitStrategy).V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko
> ==>marko {code}
> Early Limit strategy pulls Limit in front of map steps. However not all map
> steps allow the cardinality of the results flowing to be same.
>
> As is shown in example above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (TINKERPOP-3045) EarlyLimitStrategy is too aggresive to promote Limit and thus causing incorrect results
[
https://issues.apache.org/jira/browse/TINKERPOP-3045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17813633#comment-17813633
]
ASF GitHub Bot commented on TINKERPOP-3045:
---
spmallette commented on code in PR #2475:
URL: https://github.com/apache/tinkerpop/pull/2475#discussion_r1475959778
##
gremlin-test/src/main/resources/org/apache/tinkerpop/gremlin/test/features/filter/Range.feature:
##
@@ -280,4 +280,16 @@ Feature: Step - range()
When iterated to list
Then the result should be unordered
| result |
- | d[29].i |
\ No newline at end of file
+ | d[29].i |
+
+ Scenario: g_V_mapXinX_limitX2X_valuesXnameX
+Given the modern graph
+And the traversal of
+ """
+ g.V().map(__.in()).limit(2).values('name')
Review Comment:
nit: we prefer double quotes for strings in our feature tests as a
convention.
> EarlyLimitStrategy is too aggresive to promote Limit and thus causing
> incorrect results
> ---
>
> Key: TINKERPOP-3045
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3045
> Project: TinkerPop
> Issue Type: Bug
> Components: process
>Affects Versions: 3.6.6
> Environment: ALL
>Reporter: Prashant
>Priority: Major
> Labels: easyfix
> Fix For: 3.6.7
>
>
> {code:java}
> gremlin> g.V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko{code}
> {code:java}
> gremlin>
> g.withoutStrategies(EarlyLimitStrategy).V().map(__.in().hasId('1')).limit(2).values('name')
> ==>marko
> ==>marko {code}
> Early Limit strategy pulls Limit in front of map steps. However not all map
> steps allow the cardinality of the results flowing to be same.
>
> As is shown in example above.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
