[jira] [Resolved] (TINKERPOP-2956) Update gremlint version for the published application

2023-06-02 Thread Cole Greer (Jira)


 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cole Greer resolved TINKERPOP-2956.
---
  Assignee: Cole Greer
Resolution: Fixed

> Update gremlint version for the published application
> -
>
> Key: TINKERPOP-2956
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2956
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: gremlint
>Affects Versions: 3.5.6
>Reporter: Stephen Mallette
>Assignee: Cole Greer
>Priority: Blocker
>
> https://tinkerpop.apache.org/gremlint/ shows Gremlin 3.5.2. It should match 
> the most current version that has been released. Currently that would be 
> 3.6.4. The version is taken from {{package.json}} and the gremlint version 
> specified there i think. Not sure how this is best resolved per branch, but 
> need to make appropriate adjustments and probably update the dev docs to 
> verify the appropriate version is present on release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TINKERPOP-2956) Update gremlint version for the published application

2023-06-02 Thread Cole Greer (Jira)


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728892#comment-17728892
 ] 

Cole Greer commented on TINKERPOP-2956:
---

Fixed with CTR: 
https://github.com/apache/tinkerpop/commit/6a62327d1cb82b8abfc6080e31866212c09a0fb7

> Update gremlint version for the published application
> -
>
> Key: TINKERPOP-2956
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2956
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: gremlint
>Affects Versions: 3.5.6
>Reporter: Stephen Mallette
>Priority: Blocker
>
> https://tinkerpop.apache.org/gremlint/ shows Gremlin 3.5.2. It should match 
> the most current version that has been released. Currently that would be 
> 3.6.4. The version is taken from {{package.json}} and the gremlint version 
> specified there i think. Not sure how this is best resolved per branch, but 
> need to make appropriate adjustments and probably update the dev docs to 
> verify the appropriate version is present on release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties

2023-06-02 Thread Kelvin Lawrence (Jira)


 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2957?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kelvin Lawrence updated TINKERPOP-2957:
---
Description: 
A Gremlin user let me know about the following issue. If the query below is run 
twice, the name parameter on the 4567 vertex does not get updated. The name on 
the 1234 vertex does get updated. The query is written this way as not all 
databases support single cardinality as the default. The issue has been 
reproduced using both TinkerGraph and Amazon Neptune.
{code:java}
g.mergeV([(T.id): 'test-test-1234']).
  option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
  option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
 mergeV([(T.id): 'test-test-4567']).
  option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
  option(onMatch, 
sideEffect(property(single,"name","name2")).constant([:])){code}

  was:
A Gremlin user let me know about the following issue. If the query below is run 
twice, the name parameter on the 4567 vertex does not get updated. The name on 
the 1234 vertex does get updated. The query is written this way as not all 
databases support single cardinality as the default. The issue has been 
reproduced using both TinkerGraph and Amazon Neptune.
g.mergeV([(T.id): 'test-test-1234']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
mergeV([(T.id): 'test-test-4567']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:]))


> mergeV with sideEffect not correctly updating properties
> 
>
> Key: TINKERPOP-2957
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2957
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.6.4
>Reporter: Kelvin Lawrence
>Priority: Major
>
> A Gremlin user let me know about the following issue. If the query below is 
> run twice, the name parameter on the 4567 vertex does not get updated. The 
> name on the 1234 vertex does get updated. The query is written this way as 
> not all databases support single cardinality as the default. The issue has 
> been reproduced using both TinkerGraph and Amazon Neptune.
> {code:java}
> g.mergeV([(T.id): 'test-test-1234']).
>   option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
>   option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
>  mergeV([(T.id): 'test-test-4567']).
>   option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
>   option(onMatch, 
> sideEffect(property(single,"name","name2")).constant([:])){code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TINKERPOP-2957) mergeV with sideEffect not correctly updating properties

2023-06-02 Thread Kelvin Lawrence (Jira)
Kelvin Lawrence created TINKERPOP-2957:
--

 Summary: mergeV with sideEffect not correctly updating properties
 Key: TINKERPOP-2957
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2957
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.6.4
Reporter: Kelvin Lawrence


A Gremlin user let me know about the following issue. If the query below is run 
twice, the name parameter on the 4567 vertex does not get updated. The name on 
the 1234 vertex does get updated. The query is written this way as not all 
databases support single cardinality as the default. The issue has been 
reproduced using both TinkerGraph and Amazon Neptune.
g.mergeV([(T.id): 'test-test-1234']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:])).
mergeV([(T.id): 'test-test-4567']).
option(onCreate, [(T.label): 'someLabel', 'name': 'name1']).
option(onMatch, sideEffect(property(single,"name","name2")).constant([:]))



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TINKERPOP-2952) Error when overriding DSL methods

2023-06-02 Thread Stephen Mallette (Jira)


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728819#comment-17728819
 ] 

Stephen Mallette commented on TINKERPOP-2952:
-

i did experiment with a [rough patch 
|https://issues.apache.org/jira/secure/attachment/13058756/dsl.patch] just to 
see how it could work then came to the realization that i expressed in my 
previous comment. it does allow the override it seems, so i figured i'd share 
it here for reference in case others feel differently about allowing this.

> Error when overriding DSL methods
> -
>
> Key: TINKERPOP-2952
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2952
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.6.2
>Reporter: Drew Nuttall-Smith
>Priority: Major
> Attachments: dsl.patch
>
>
> I'm implementing a custom gremlin DSL in java, and due to some interesting 
> requirements, I'm trying to override the `properties` method from the 
> GraphTraversal class.
>  
> Doing so results in a compilation error (see below) due to the method already 
> being defined. It looks like the DSL code generation is loading in the custom 
> methods, and then loading in the built in methods and the `@Override` 
> annotation is ignored.
>  
>  
> Error:
> {{[ERROR] 
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/DatastageTraversal.java:[223,62]
>  method properties(java.lang.String...) is already defined in interface 
> com.datamigrators.mettle.compliance.gremlin.dsl.DatastageTraversal}}
> {{[ERROR] 
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/__.java:[192,85]
>  name clash: properties(java.lang.String...) and 
> properties(java.lang.String...) have the same erasure}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TINKERPOP-2952) Error when overriding DSL methods

2023-06-02 Thread Stephen Mallette (Jira)


 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Mallette updated TINKERPOP-2952:

Attachment: dsl.patch

> Error when overriding DSL methods
> -
>
> Key: TINKERPOP-2952
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2952
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.6.2
>Reporter: Drew Nuttall-Smith
>Priority: Major
> Attachments: dsl.patch
>
>
> I'm implementing a custom gremlin DSL in java, and due to some interesting 
> requirements, I'm trying to override the `properties` method from the 
> GraphTraversal class.
>  
> Doing so results in a compilation error (see below) due to the method already 
> being defined. It looks like the DSL code generation is loading in the custom 
> methods, and then loading in the built in methods and the `@Override` 
> annotation is ignored.
>  
>  
> Error:
> {{[ERROR] 
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/DatastageTraversal.java:[223,62]
>  method properties(java.lang.String...) is already defined in interface 
> com.datamigrators.mettle.compliance.gremlin.dsl.DatastageTraversal}}
> {{[ERROR] 
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/__.java:[192,85]
>  name clash: properties(java.lang.String...) and 
> properties(java.lang.String...) have the same erasure}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (TINKERPOP-2952) Error when overriding DSL methods

2023-06-02 Thread Stephen Mallette (Jira)


[ 
https://issues.apache.org/jira/browse/TINKERPOP-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17728817#comment-17728817
 ] 

Stephen Mallette commented on TINKERPOP-2952:
-

sorry, it took some time for me to get back to this. i was able to recreate the 
problem with your example. i'm not sure what i did to get it to work. perhaps i 
just was mistaken that it was working at all. 

i'm not sure that this is a bug necessarily as i'm not sure that it's the DSLs 
purpose to override existing step functionality. It's purpose is to provide new 
domain specific steps that offer functionality composed from existing steps. If 
you have functionality you want in {{properties(String...)}} i think the 
correct thing to do is to create a new step all together called 
{{myProperties(String...)}} (or whatever domain specific name makes sense). 

While I can see why folks might want to simply add features to existing steps, 
I think that if we allow this to work it makes Gremlin less readable because 
`properties(String...)` may or may not behave like the actual Gremlin 
definition of {{properties(String...)}}. I'm inclined to keep this working the 
way that it does and to update the documentation to make it clear that this is 
intended behavior.

> Error when overriding DSL methods
> -
>
> Key: TINKERPOP-2952
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2952
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.6.2
>Reporter: Drew Nuttall-Smith
>Priority: Major
>
> I'm implementing a custom gremlin DSL in java, and due to some interesting 
> requirements, I'm trying to override the `properties` method from the 
> GraphTraversal class.
>  
> Doing so results in a compilation error (see below) due to the method already 
> being defined. It looks like the DSL code generation is loading in the custom 
> methods, and then loading in the built in methods and the `@Override` 
> annotation is ignored.
>  
>  
> Error:
> {{[ERROR] 
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/DatastageTraversal.java:[223,62]
>  method properties(java.lang.String...) is already defined in interface 
> com.datamigrators.mettle.compliance.gremlin.dsl.DatastageTraversal}}
> {{[ERROR] 
> /Users/drewnuttall-smith/Documents/work/projects/compliance/dm-mettle-nextgen-compliance/target/generated-sources/annotations/com/datamigrators/mettle/compliance/gremlin/dsl/__.java:[192,85]
>  name clash: properties(java.lang.String...) and 
> properties(java.lang.String...) have the same erasure}}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Updated] (TINKERPOP-2954) Pass Gremlin Version from Maven to Java Without Manifests

2023-06-02 Thread Stephen Mallette (Jira)


 [ 
https://issues.apache.org/jira/browse/TINKERPOP-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stephen Mallette updated TINKERPOP-2954:

Priority: Critical  (was: Major)

> Pass Gremlin Version from Maven to Java Without Manifests
> -
>
> Key: TINKERPOP-2954
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2954
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.5.6, 3.6.4
>Reporter: Cole Greer
>Priority: Critical
>
> Currently maven will store the current version of TinkerPop in the Manifest 
> file which is packaged in all of the java jars where it can be read via jcabi 
> manifests.
> While this system works well in most cases, it has proven unreliable in 
> others. I have seen multiple cases where way in which users include TinkerPop 
> into their project results in the manifest being lost, and the version 
> becoming unavailable.
> It would be nice to switch to an alternative system which does not rely on 
> extra files being packaged in distributions. It would also be nice to have a 
> solution which could easily be extended to all GLV's. A possible solution 
> would be configuring Maven to directly inject the version into source code.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Created] (TINKERPOP-2956) Update gremlint version for the published application

2023-06-02 Thread Stephen Mallette (Jira)
Stephen Mallette created TINKERPOP-2956:
---

 Summary: Update gremlint version for the published application
 Key: TINKERPOP-2956
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2956
 Project: TinkerPop
  Issue Type: Improvement
  Components: gremlint
Affects Versions: 3.5.6
Reporter: Stephen Mallette


https://tinkerpop.apache.org/gremlint/ shows Gremlin 3.5.2. It should match the 
most current version that has been released. Currently that would be 3.6.4. The 
version is taken from {{package.json}} and the gremlint version specified there 
i think. Not sure how this is best resolved per branch, but need to make 
appropriate adjustments and probably update the dev docs to verify the 
appropriate version is present on release.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)