[GitHub] tinkerpop issue #798: TINKERPOP-1857 - Consistency in GLV tests

[jorgebay]

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/798
  
The increased coverage is great!

I'm still puzzled by ticket 1891 (`P.not()` serialization) but that's a 
different issue.

VOTE +1


---

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Stephen Mallette]

>  Perhaps if there was a way to specify a custom "__" class to the
ImportCustomizer, this would all solve itself?

yes - it might. i don't think we should go down that path though. first of
all, i think the workaround i suggested seems like the way to do this
within the context of what we have right now (unless that doesn't work for
some reason). second, the approach you're taking with DSLs is not really
something we are planning on directly supporting - it's availability is a
bit of a side-effect of many other older design decisions. Going forward,
I'd say that the consensus on TinkerPop's general direction is:

1. prefer sessionless requests over sessions
2. bytecode based traversal are the future, not scripts
3. DSLs are a client side feature and are designed with item 2 in mind

Is there a particular use case you are trying to satisfy that forces you
down the path of sessions and server-side DSLs? I think we've all spent a
fair time considering where 1-3 breaks down and how important those break
downs are for usability. To me, the main use case for server-side DSLs
would be if you had some custom steps that you'd written that you wanted in
the DSL. But, to me, that's almost past DSL level. If you're doing that,
you've drifted into the general category of Graph System Provider and if
you've done that, then you have a very heavy weight implementation to
manage and as such you are in the minority of users (and thus - little
impact with that breakdown).

Don't want to panic anyone with 1-3 if you're new to the listIt's not
like TinkerPop 3.4.0 is going to drop script support or anything like that.
I'm just trying to say that developers who want to be most inline with the
latest thinking on the future direction of the project should look to
conform to 1-3 where possible.


On Wed, Feb 14, 2018 at 6:41 PM, Moore, Branden James 
wrote:

> I think I figured out why 'label' isn't getting imported...   It is being
> overwritten in the import map by the  __.label() method static import.
>  Normally, the CoreGremlinPlugin imports 'T.label' and '__.label()'  is
> filtered out of the imports on line 59 of ImportGroovyCustomizer.java  (It
> was probably taken care of via line 55).
>
> Perhaps if there was a way to specify a custom "__" class to the
> ImportCustomizer, this would all solve itself?
>
>
> On 2/14/18, 12:32 PM, "Stephen Mallette"  wrote:
>
> Sorry - those imports are really mysterious to me. I dug through a
> fair bit
> of groovy code trying to figure out what the rules were for that import
> stuff and i don't recall getting to the bottom of it.
>
> On Wed, Feb 14, 2018 at 2:27 PM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > So I did a quick experiment of:
> >
> > --- a/gremlin-groovy/src/main/java/org/apache/tinkerpop/
> > gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
> > +++ b/gremlin-groovy/src/main/java/org/apache/tinkerpop/
> > gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
> > -CoreGremlinPlugin.instance().getCustomizers("gremlin-
> groovy").ifPresent(c
> > -> listOfCustomizers.addAll(Arrays.asList(c)));
> > +CoreGremlinPlugin.instance().getCustomizers("gremlin-
> groovy").ifPresent(c
> > -> listOfCustomizers.addAll(0, Arrays.asList(c)));
> >
> >
> > While this does allow my DSL's __ to be the one found, oddly, some
> other
> > static imports no longer appear in the interpreter; specifically
> 'label'.
> > (Referencing 'T.label' works fine.)  It isn't that the symbol lookup
> finds
> > the incorrect class; I get the error "groovy.lang.
> MissingPropertyException:
> > No such property: label for class: Script2", however, some other
> enums (ie,
> > 'incr') are imported just fine.
> >
> > Any ideas why that would occur?
> >
> > On 2/14/18, 10:46 AM, "Stephen Mallette" 
> wrote:
> >
> > There was a time when I looked into that in pretty grave detail.
> I
> > don't
> > recall my findings exactly, but I obviously didn't come up with
> a nice
> > solution. I'm not sure that I ever became convinced that any of
> this
> > groovy
> > import stuff behaves in a completely deterministic way. I
> suppose you
> > could
> > try it out and see if that change helps or not
> >
> > On Wed, Feb 14, 2018 at 12:42 PM, Moore, Branden James <
> > bjm...@sandia.gov>
> > wrote:
> >
> > > Thanks for fixing issue #1.   I figured that one would be easy
> to
> > fix.
> > >
> > > As for issue #2, I'm wondering if changing the
> > GremlinGroovyScriptEngine
> > > to add it's ImportCustomizer  (line 247) to the beginning of
> the
> > list of
> > > customizers, rather than the end, would allow DSLs (and any
> other
> > imports)
> > > to override the default Gremlin 

[jira] [Commented] (TINKERPOP-1857) GLV test suite consistency and completeness

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TINKERPOP-1857:
---

Github user jorgebay commented on the issue:

https://github.com/apache/tinkerpop/pull/798
  
The increased coverage is great!

I'm still puzzled by ticket 1891 (`P.not()` serialization) but that's a 
different issue.

VOTE +1


> GLV test suite consistency and completeness
> ---
>
> Key: TINKERPOP-1857
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1857
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.7
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> While the GLV test suite was largely completed in 3.2.7/3.3.1 there were a 
> number of tests that weren't fully migrated and minor naming inconsistencies 
> that needed to be addressed. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (TINKERPOP-1892) GLV test failures for .NET

[stephen mallette (JIRA)]

stephen mallette created TINKERPOP-1892:
---

 Summary: GLV test failures for .NET
 Key: TINKERPOP-1892
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1892
 Project: TinkerPop
  Issue Type: Bug
  Components: dotnet
Affects Versions: 3.2.7
Reporter: stephen mallette
 Fix For: 3.2.8, 3.3.2


There are a number of test failures with the latest updates to the GLV test 
suite on TINKERPOP-1857. Those tests have been "ignored" in 
{{GherkinTestRunner}}. I wasn't able to discern a pattern there to make this 
ticket any more specific. Hopefully once someone digs into this one, a better 
title can be written or more specific JIRA issues can be produced. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-620) Commutative Step Marker interface

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-620.
--
Resolution: Won't Do

Given that there hasn't been any additional discussion here in some time, I'm 
going to close this. 

> Commutative Step Marker interface
> -
>
> Key: TINKERPOP-620
> URL: https://issues.apache.org/jira/browse/TINKERPOP-620
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matthias Broecheler
>Priority: Major
>
> Some steps can be reordered, i.e. they are commutative. For instance, 
> has-steps can be reordered without affecting the pipeline. When writing a 
> query optimizer I am often in a situation where I can only optimize a subset 
> of the supported steps and I might want to reorder them so that I can group 
> all the optimizable steps together. Currently, I have to manually identify 
> the commutative steps for that. It would be much nicer if TinkerPop could 
> have a "Commutative" marker interface for that and use it consistently.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Moore, Branden James]

Now that python-gremlin is mature enough to use and extend, I'm working to 
migrate our environment to a fully session-less, bytecode-based environment.  
However, we currently have significant amounts of "legacy" groovy/gremlin 
hanging around.  Until all of that can be migrated, we still need to use the 
older model.

We do have a handful of custom steps that are not implemented as combinations 
of existing Gremlin steps, which does drive us to a server-side DSL.

Do you expect to *NOT* support server-side DSLs in the future (even as 
Bytecode)?


On 2/15/18, 6:08 AM, "Stephen Mallette"  wrote:

>  Perhaps if there was a way to specify a custom "__" class to the
ImportCustomizer, this would all solve itself?

yes - it might. i don't think we should go down that path though. first of
all, i think the workaround i suggested seems like the way to do this
within the context of what we have right now (unless that doesn't work for
some reason). second, the approach you're taking with DSLs is not really
something we are planning on directly supporting - it's availability is a
bit of a side-effect of many other older design decisions. Going forward,
I'd say that the consensus on TinkerPop's general direction is:

1. prefer sessionless requests over sessions
2. bytecode based traversal are the future, not scripts
3. DSLs are a client side feature and are designed with item 2 in mind

Is there a particular use case you are trying to satisfy that forces you
down the path of sessions and server-side DSLs? I think we've all spent a
fair time considering where 1-3 breaks down and how important those break
downs are for usability. To me, the main use case for server-side DSLs
would be if you had some custom steps that you'd written that you wanted in
the DSL. But, to me, that's almost past DSL level. If you're doing that,
you've drifted into the general category of Graph System Provider and if
you've done that, then you have a very heavy weight implementation to
manage and as such you are in the minority of users (and thus - little
impact with that breakdown).

Don't want to panic anyone with 1-3 if you're new to the listIt's not
like TinkerPop 3.4.0 is going to drop script support or anything like that.
I'm just trying to say that developers who want to be most inline with the
latest thinking on the future direction of the project should look to
conform to 1-3 where possible.


On Wed, Feb 14, 2018 at 6:41 PM, Moore, Branden James 
wrote:

> I think I figured out why 'label' isn't getting imported...   It is being
> overwritten in the import map by the  __.label() method static import.
>  Normally, the CoreGremlinPlugin imports 'T.label' and '__.label()'  is
> filtered out of the imports on line 59 of ImportGroovyCustomizer.java  (It
> was probably taken care of via line 55).
>
> Perhaps if there was a way to specify a custom "__" class to the
> ImportCustomizer, this would all solve itself?
>
>
> On 2/14/18, 12:32 PM, "Stephen Mallette"  wrote:
>
> Sorry - those imports are really mysterious to me. I dug through a
> fair bit
> of groovy code trying to figure out what the rules were for that 
import
> stuff and i don't recall getting to the bottom of it.
>
> On Wed, Feb 14, 2018 at 2:27 PM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > So I did a quick experiment of:
> >
> > --- a/gremlin-groovy/src/main/java/org/apache/tinkerpop/
> > gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
> > +++ b/gremlin-groovy/src/main/java/org/apache/tinkerpop/
> > gremlin/groovy/jsr223/GremlinGroovyScriptEngine.java
> > -CoreGremlinPlugin.instance().getCustomizers("gremlin-
> groovy").ifPresent(c
> > -> listOfCustomizers.addAll(Arrays.asList(c)));
> > +CoreGremlinPlugin.instance().getCustomizers("gremlin-
> groovy").ifPresent(c
> > -> listOfCustomizers.addAll(0, Arrays.asList(c)));
> >
> >
> > While this does allow my DSL's __ to be the one found, oddly, some
> other
> > static imports no longer appear in the interpreter; specifically
> 'label'.
> > (Referencing 'T.label' works fine.)  It isn't that the symbol lookup
> finds
> > the incorrect class; I get the error "groovy.lang.
> MissingPropertyException:
> > No such property: label for class: Script2", however, some other
> enums (ie,
> > 'incr') are imported just fine.
> >
> > Any ideas why that would occur?
> >
> > On 2/14/18, 10:46 AM, "Stephen Mallette" 
> wrote:
> >
> > There was a time 

[jira] [Updated] (TINKERPOP-1357) Centrality Recipes should mention pageRank and OLAP.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1357:

Component/s: (was: process)

> Centrality Recipes should mention pageRank and OLAP.
> 
>
> Key: TINKERPOP-1357
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1357
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> While we don't have many OLAP graph algorithm implemented off of 
> `GraphTraversal`, we should really have `pageRank()` discussed in the 
> centrality recipes section in the eigenvector section.
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/recipes/#eigenvector-centrality



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-1357) Centrality Recipes should mention pageRank and OLAP.

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1357.
---
   Resolution: Done
 Assignee: stephen mallette
Fix Version/s: 3.3.2
   3.2.8

I added in a mention of {{pageRank()}}

https://github.com/apache/tinkerpop/commit/d63aaa852bfc605b3ddee5d1471097a724279cd0

> Centrality Recipes should mention pageRank and OLAP.
> 
>
> Key: TINKERPOP-1357
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1357
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: stephen mallette
>Priority: Major
> Fix For: 3.2.8, 3.3.2
>
>
> While we don't have many OLAP graph algorithm implemented off of 
> `GraphTraversal`, we should really have `pageRank()` discussed in the 
> centrality recipes section in the eigenvector section.
> http://tinkerpop.apache.org/docs/3.2.1-SNAPSHOT/recipes/#eigenvector-centrality



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1788) gremlin.sh does not work correctly under Cygwin

[Michael McDermott (JIRA)]

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

Michael McDermott commented on TINKERPOP-1788:
--

Sorry for the slow response myself. The problem persists. I tried it again this 
morning on a fresh download of Gremlin Console 3.3.1. The result after unpack 
is below.

{{> $ ./bin/gremlin.sh}}
{{./bin/gremlin.sh: line 52: 
lib/caffeine-2.3.1.jar;lib/commons-cli-1.2.jar;lib/commons-codec-1.9.jar;lib/commons-configuration-1.10.jar;lib/commons-lang-2.6.jar;lib/commons-lang3-3.3.1.jar;lib/commons-logging-1.2.jar;lib/exp4j-0.4.8.jar;lib/gbench-0.4.3-groovy-2.4.jar;lib/gprof-0.3.1-groovy-2.4.jar;lib/gremlin-console-3.3.1.jar;lib/gremlin-core-3.3.1.jar;lib/gremlin-driver-3.3.1.jar;lib/gremlin-shaded-3.3.1.jar;lib/groovy-2.4.11.jar;lib/groovy-2.4.11-indy.jar;lib/groovy-console-2.4.11.jar;lib/groovy-groovysh-2.4.11-indy.jar;lib/groovy-json-2.4.11-indy.jar;lib/groovy-jsr223-2.4.11-indy.jar;lib/groovy-sql-2.4.11-indy.jar;lib/groovy-swing-2.4.11.jar;lib/groovy-templates-2.4.11.jar;lib/groovy-xml-2.4.11.jar;lib/hppc-0.7.1.jar;lib/httpclient-4.5.1.jar;lib/httpcore-4.4.3.jar;lib/ivy-2.3.0.jar;lib/javapoet-1.8.0.jar;lib/javatuples-1.2.jar;lib/jbcrypt-0.4.jar;lib/jcabi-log-0.14.jar;lib/jcabi-manifests-1.1.jar;lib/jcl-over-slf4j-1.7.21.jar;lib/jline-2.12.jar;lib/log4j-1.2.17.jar;lib/netty-all-4.0.53.Final.jar;lib/slf4j-api-1.7.21.jar;lib/slf4j-log4j12-1.7.21.jar;lib/snakeyaml-1.15.jar;.:
 No such file or directory}}

Note that, by comparison, running the batch version works fine.

{{> $ ./bin/gremlin.bat}}

{{ \,,,/}}
{{ (o o)}}
{{-oOOo-(3)-oOOo-}}
{{plugin activated: tinkerpop.server}}
{{plugin activated: tinkerpop.utilities}}
{{plugin activated: tinkerpop.tinkergraph}}
{{gremlin>}}

This goes back to the partial patch sent in previously, where the shell script 
does not make adjustments for Cygwin. That's the reason for the checks against 
uname there.

 

> gremlin.sh does not work correctly under Cygwin
> ---
>
> Key: TINKERPOP-1788
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1788
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.3.0
>Reporter: Michael McDermott
>Priority: Major
> Attachments: gremlin.sh
>
>
> On my machine (Windows 10), I have a Cygwin setup. Attempting to execute 
> gremlin.sh to launch the console errors out. gremlin.bat under cmd runs fine, 
> so I have the general prerequisites (Java, etc.).
> I have partially patched out the shell script (modified off of 3.3.0 
> attached) and it no longer errors out (I initially received issues around CP 
> setting and absolute paths). The big issues I identified were inconsistent 
> usage of the separate classpath separator on Cygwin (; vs. :) and that 
> absolute paths need to be translated when running under Cygwin.
> Something is still broken, though, as I cannot use the shell after it starts 
> up (note that this trivial example works fine in cmd):
> {code}
> gremlin> :plugin list
> :plugin list
> ==>tinkerpop.server
> ==>tinkerpop.gephi
> ==>tinkerpop.utilities
> ==>tinkerpop.sugar
> ==>tinkerpop.credentials
> ==>tinkerpop.hadoop
> ==>tinkerpop.tinkergraph
> gremlin>  g = TinkerFactory.createModern()
>  g = TinkerFactory.createModern()
> No such property: TinkerFactory for class: groovysh_evaluate
> Type ':help' or ':h' for help.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1788) gremlin.sh does not work correctly under Cygwin

[Michael McDermott (JIRA)]

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

Michael McDermott commented on TINKERPOP-1788:
--

It occurs to me that there may be one thing not clear from what I wrote before. 
Cygwin is an interesting hybrid between Windows and *nix style executions 
because there is no JRE distributed with Cygwin. Therefore, running the script 
under Cygwin causes *nix style shell to run that executes Windows style Java, 
which includes differences in how you delimit classpath issues. This is why you 
see many shell scripts, including those from other Apache projects, check for a 
uname = CYGWIN.

> gremlin.sh does not work correctly under Cygwin
> ---
>
> Key: TINKERPOP-1788
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1788
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.3.0
>Reporter: Michael McDermott
>Priority: Major
> Attachments: gremlin.sh
>
>
> On my machine (Windows 10), I have a Cygwin setup. Attempting to execute 
> gremlin.sh to launch the console errors out. gremlin.bat under cmd runs fine, 
> so I have the general prerequisites (Java, etc.).
> I have partially patched out the shell script (modified off of 3.3.0 
> attached) and it no longer errors out (I initially received issues around CP 
> setting and absolute paths). The big issues I identified were inconsistent 
> usage of the separate classpath separator on Cygwin (; vs. :) and that 
> absolute paths need to be translated when running under Cygwin.
> Something is still broken, though, as I cannot use the shell after it starts 
> up (note that this trivial example works fine in cmd):
> {code}
> gremlin> :plugin list
> :plugin list
> ==>tinkerpop.server
> ==>tinkerpop.gephi
> ==>tinkerpop.utilities
> ==>tinkerpop.sugar
> ==>tinkerpop.credentials
> ==>tinkerpop.hadoop
> ==>tinkerpop.tinkergraph
> gremlin>  g = TinkerFactory.createModern()
>  g = TinkerFactory.createModern()
> No such property: TinkerFactory for class: groovysh_evaluate
> Type ':help' or ':h' for help.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (TINKERPOP-1788) gremlin.sh does not work correctly under Cygwin

[stephen mallette (JIRA)]

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

stephen mallette commented on TINKERPOP-1788:
-

[~Florian Hockmann] is this something you can look into on your windows system?

> gremlin.sh does not work correctly under Cygwin
> ---
>
> Key: TINKERPOP-1788
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1788
> Project: TinkerPop
>  Issue Type: Bug
>  Components: console
>Affects Versions: 3.3.0
>Reporter: Michael McDermott
>Priority: Major
> Attachments: gremlin.sh
>
>
> On my machine (Windows 10), I have a Cygwin setup. Attempting to execute 
> gremlin.sh to launch the console errors out. gremlin.bat under cmd runs fine, 
> so I have the general prerequisites (Java, etc.).
> I have partially patched out the shell script (modified off of 3.3.0 
> attached) and it no longer errors out (I initially received issues around CP 
> setting and absolute paths). The big issues I identified were inconsistent 
> usage of the separate classpath separator on Cygwin (; vs. :) and that 
> absolute paths need to be translated when running under Cygwin.
> Something is still broken, though, as I cannot use the shell after it starts 
> up (note that this trivial example works fine in cmd):
> {code}
> gremlin> :plugin list
> :plugin list
> ==>tinkerpop.server
> ==>tinkerpop.gephi
> ==>tinkerpop.utilities
> ==>tinkerpop.sugar
> ==>tinkerpop.credentials
> ==>tinkerpop.hadoop
> ==>tinkerpop.tinkergraph
> gremlin>  g = TinkerFactory.createModern()
>  g = TinkerFactory.createModern()
> No such property: TinkerFactory for class: groovysh_evaluate
> Type ':help' or ':h' for help.
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Stephen Mallette]

>  Do you expect to *NOT* support server-side DSLs in the future (even as
Bytecode)?

I think that's it's a bit early to say that definitively, but all community
discussion thus far has pointed in the direction of keeping DSLs a
client-side construct, so I'd expect that we would not do much work to
support them (i.e. make them easier to implement, write documentation,
discuss them as best practices, etc) in an official capacity for end-users.

There are a lot of reasons for that (some technical and some not), but I
think that one of the biggest ones I tend to think of the most these days
is that we are seeing more and more TinkerPop-enabled. graph systems that
are server oriented (e.g. DSE Graph) or simply a managed service (e.g
CosmosDB) which don't allow a lot of control of what happens on the server.
They just accept bytecode/scripts, process them and send results. Embracing
that model from the TinkerPop perspective vastly simplifies the interfaces
we need to expose to Graph System Providers who want to be
TinkerPop-enabled and vastly reduces the surface area of interaction that
users have to face to use Gremlin. When I consider embracing that model in
relation to DSLs, I tend to see DSLs as lightweight client-only
implementations that don't introduce headaches to the Graph Systems for
which TinkerPop doesn't really offer much answer (e.g how do i allow users
to deploy code to the servers, can i allow custom steps to be deployed
securely, what about serialization of these custom steps?). I think we'd
want to take those issues off the table.

>  We do have a handful of custom steps

That's interesting. Again, I think this puts you in a different category
that goes beyond what DSLs were intended for. Going down this route makes
for highly advanced usage. Custom steps on the server would mean a GLV
would need to be extended to support those steps which ties into bytecode
serialization for both client and server. Complicated stuff without use of
scripts (which is why you are using them i gather).

Can you talk about what those custom steps do? Do you also have custom
TraversalStrategies which interact with them?


On Thu, Feb 15, 2018 at 10:17 AM, Moore, Branden James 
wrote:

> Now that python-gremlin is mature enough to use and extend, I'm working to
> migrate our environment to a fully session-less, bytecode-based
> environment.  However, we currently have significant amounts of "legacy"
> groovy/gremlin hanging around.  Until all of that can be migrated, we still
> need to use the older model.
>
> We do have a handful of custom steps that are not implemented as
> combinations of existing Gremlin steps, which does drive us to a
> server-side DSL.
>
> Do you expect to *NOT* support server-side DSLs in the future (even as
> Bytecode)?
>
>
> On 2/15/18, 6:08 AM, "Stephen Mallette"  wrote:
>
> >  Perhaps if there was a way to specify a custom "__" class to the
> ImportCustomizer, this would all solve itself?
>
> yes - it might. i don't think we should go down that path though.
> first of
> all, i think the workaround i suggested seems like the way to do this
> within the context of what we have right now (unless that doesn't work
> for
> some reason). second, the approach you're taking with DSLs is not
> really
> something we are planning on directly supporting - it's availability
> is a
> bit of a side-effect of many other older design decisions. Going
> forward,
> I'd say that the consensus on TinkerPop's general direction is:
>
> 1. prefer sessionless requests over sessions
> 2. bytecode based traversal are the future, not scripts
> 3. DSLs are a client side feature and are designed with item 2 in mind
>
> Is there a particular use case you are trying to satisfy that forces
> you
> down the path of sessions and server-side DSLs? I think we've all
> spent a
> fair time considering where 1-3 breaks down and how important those
> break
> downs are for usability. To me, the main use case for server-side DSLs
> would be if you had some custom steps that you'd written that you
> wanted in
> the DSL. But, to me, that's almost past DSL level. If you're doing
> that,
> you've drifted into the general category of Graph System Provider and
> if
> you've done that, then you have a very heavy weight implementation to
> manage and as such you are in the minority of users (and thus - little
> impact with that breakdown).
>
> Don't want to panic anyone with 1-3 if you're new to the listIt's
> not
> like TinkerPop 3.4.0 is going to drop script support or anything like
> that.
> I'm just trying to say that developers who want to be most inline with
> the
> latest thinking on the future direction of the project should look to
> conform to 1-3 where possible.
>
>
> On Wed, Feb 14, 2018 at 6:41 PM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > I 

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Stephen Mallette]

Cool. I flip/flop back and forth about having better support for general
predicates (like text and geo) - seems like this would be a argument in
favor of adding such things to resolve this problem of having to write
server side DSL code. if done right it might save graph providers from
having to write their on extensions to GLVs .

Out of curiosity, what graph database are you using?

On Thu, Feb 15, 2018 at 11:39 AM, Moore, Branden James 
wrote:

> >Can you talk about what those custom steps do? Do you also have custom
>  >   TraversalStrategies which interact with them?
>
> We do not have any custom TraversalStrategies yet.
>
> We do have custom predicates, though not many...  Mostly string operations
> (textContains, textRegex).
>
> Most of our custom steps can be implemented as plain Gremlin, however,
> we've found that because we know the shape of our graphs (it starts with an
> explicit tree structure, with other edges layered on top), we can write
> some steps more efficiently, or just more easily, as direct TinkerPop java
> Vertex/Edge operations.
>
> One of our custom steps, however, is a work-around to the fact that the
> NESTED_LOOP traversal requirement, still, cannot be met.
>
>
>
> On 2/15/18, 9:10 AM, "Stephen Mallette"  wrote:
>
> >  Do you expect to *NOT* support server-side DSLs in the future (even
> as
> Bytecode)?
>
> I think that's it's a bit early to say that definitively, but all
> community
> discussion thus far has pointed in the direction of keeping DSLs a
> client-side construct, so I'd expect that we would not do much work to
> support them (i.e. make them easier to implement, write documentation,
> discuss them as best practices, etc) in an official capacity for
> end-users.
>
> There are a lot of reasons for that (some technical and some not), but
> I
> think that one of the biggest ones I tend to think of the most these
> days
> is that we are seeing more and more TinkerPop-enabled. graph systems
> that
> are server oriented (e.g. DSE Graph) or simply a managed service (e.g
> CosmosDB) which don't allow a lot of control of what happens on the
> server.
> They just accept bytecode/scripts, process them and send results.
> Embracing
> that model from the TinkerPop perspective vastly simplifies the
> interfaces
> we need to expose to Graph System Providers who want to be
> TinkerPop-enabled and vastly reduces the surface area of interaction
> that
> users have to face to use Gremlin. When I consider embracing that
> model in
> relation to DSLs, I tend to see DSLs as lightweight client-only
> implementations that don't introduce headaches to the Graph Systems for
> which TinkerPop doesn't really offer much answer (e.g how do i allow
> users
> to deploy code to the servers, can i allow custom steps to be deployed
> securely, what about serialization of these custom steps?). I think
> we'd
> want to take those issues off the table.
>
> >  We do have a handful of custom steps
>
> That's interesting. Again, I think this puts you in a different
> category
> that goes beyond what DSLs were intended for. Going down this route
> makes
> for highly advanced usage. Custom steps on the server would mean a GLV
> would need to be extended to support those steps which ties into
> bytecode
> serialization for both client and server. Complicated stuff without
> use of
> scripts (which is why you are using them i gather).
>
> Can you talk about what those custom steps do? Do you also have custom
> TraversalStrategies which interact with them?
>
>
> On Thu, Feb 15, 2018 at 10:17 AM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > Now that python-gremlin is mature enough to use and extend, I'm
> working to
> > migrate our environment to a fully session-less, bytecode-based
> > environment.  However, we currently have significant amounts of
> "legacy"
> > groovy/gremlin hanging around.  Until all of that can be migrated,
> we still
> > need to use the older model.
> >
> > We do have a handful of custom steps that are not implemented as
> > combinations of existing Gremlin steps, which does drive us to a
> > server-side DSL.
> >
> > Do you expect to *NOT* support server-side DSLs in the future (even
> as
> > Bytecode)?
> >
> >
> > On 2/15/18, 6:08 AM, "Stephen Mallette" 
> wrote:
> >
> > >  Perhaps if there was a way to specify a custom "__" class to
> the
> > ImportCustomizer, this would all solve itself?
> >
> > yes - it might. i don't think we should go down that path though.
> > first of
> > all, i think the workaround i suggested seems like the way to do
> this
> > within the context of what we have right now (unless that
> doesn't work
> > for
> > some reason). 

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Moore, Branden James]

>Can you talk about what those custom steps do? Do you also have custom
 >   TraversalStrategies which interact with them?

We do not have any custom TraversalStrategies yet.

We do have custom predicates, though not many...  Mostly string operations 
(textContains, textRegex).

Most of our custom steps can be implemented as plain Gremlin, however, we've 
found that because we know the shape of our graphs (it starts with an explicit 
tree structure, with other edges layered on top), we can write some steps more 
efficiently, or just more easily, as direct TinkerPop java Vertex/Edge 
operations.

One of our custom steps, however, is a work-around to the fact that the 
NESTED_LOOP traversal requirement, still, cannot be met.



On 2/15/18, 9:10 AM, "Stephen Mallette"  wrote:

>  Do you expect to *NOT* support server-side DSLs in the future (even as
Bytecode)?

I think that's it's a bit early to say that definitively, but all community
discussion thus far has pointed in the direction of keeping DSLs a
client-side construct, so I'd expect that we would not do much work to
support them (i.e. make them easier to implement, write documentation,
discuss them as best practices, etc) in an official capacity for end-users.

There are a lot of reasons for that (some technical and some not), but I
think that one of the biggest ones I tend to think of the most these days
is that we are seeing more and more TinkerPop-enabled. graph systems that
are server oriented (e.g. DSE Graph) or simply a managed service (e.g
CosmosDB) which don't allow a lot of control of what happens on the server.
They just accept bytecode/scripts, process them and send results. Embracing
that model from the TinkerPop perspective vastly simplifies the interfaces
we need to expose to Graph System Providers who want to be
TinkerPop-enabled and vastly reduces the surface area of interaction that
users have to face to use Gremlin. When I consider embracing that model in
relation to DSLs, I tend to see DSLs as lightweight client-only
implementations that don't introduce headaches to the Graph Systems for
which TinkerPop doesn't really offer much answer (e.g how do i allow users
to deploy code to the servers, can i allow custom steps to be deployed
securely, what about serialization of these custom steps?). I think we'd
want to take those issues off the table.

>  We do have a handful of custom steps

That's interesting. Again, I think this puts you in a different category
that goes beyond what DSLs were intended for. Going down this route makes
for highly advanced usage. Custom steps on the server would mean a GLV
would need to be extended to support those steps which ties into bytecode
serialization for both client and server. Complicated stuff without use of
scripts (which is why you are using them i gather).

Can you talk about what those custom steps do? Do you also have custom
TraversalStrategies which interact with them?


On Thu, Feb 15, 2018 at 10:17 AM, Moore, Branden James 
wrote:

> Now that python-gremlin is mature enough to use and extend, I'm working to
> migrate our environment to a fully session-less, bytecode-based
> environment.  However, we currently have significant amounts of "legacy"
> groovy/gremlin hanging around.  Until all of that can be migrated, we 
still
> need to use the older model.
>
> We do have a handful of custom steps that are not implemented as
> combinations of existing Gremlin steps, which does drive us to a
> server-side DSL.
>
> Do you expect to *NOT* support server-side DSLs in the future (even as
> Bytecode)?
>
>
> On 2/15/18, 6:08 AM, "Stephen Mallette"  wrote:
>
> >  Perhaps if there was a way to specify a custom "__" class to the
> ImportCustomizer, this would all solve itself?
>
> yes - it might. i don't think we should go down that path though.
> first of
> all, i think the workaround i suggested seems like the way to do this
> within the context of what we have right now (unless that doesn't work
> for
> some reason). second, the approach you're taking with DSLs is not
> really
> something we are planning on directly supporting - it's availability
> is a
> bit of a side-effect of many other older design decisions. Going
> forward,
> I'd say that the consensus on TinkerPop's general direction is:
>
> 1. prefer sessionless requests over sessions
> 2. bytecode based traversal are the future, not scripts
> 3. DSLs are a client side feature and are designed with item 2 in mind
>
> Is there a particular use case you are trying to satisfy that forces
> you
> down the 

[jira] [Closed] (TINKERPOP-1411) VertexProgramStrategy has a hardcode check for RemoteStrategy

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1411.
---
Resolution: Won't Do

I think it's hard to generalize here because I don't see any other strategies 
that have this issue. I think i'm just going to close this until it becomes a 
real problem in other strategies.

> VertexProgramStrategy has a hardcode check for RemoteStrategy
> -
>
> Key: TINKERPOP-1411
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1411
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: stephen mallette
>Priority: Minor
>
> In the {{apply()}} method of {{VertexProgramStrategy}} there is a hardcoded 
> check for {{RemoteStrategy}}. That hardcoding gives {{VertexProgramStrategy}} 
> a bit more knowledge about other strategies than it should have. Would be 
> better to generalize that in some way.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Stephen Mallette]

Here's the issue related to nesting repeat() steps:

https://issues.apache.org/jira/browse/TINKERPOP-967

it's not clear from the comment where marko left that one exactly. anyway,
i'm not aware of anyone actively working on that.

On Thu, Feb 15, 2018 at 1:50 PM, Moore, Branden James 
wrote:

>  >   Out of curiosity, what graph database are you using?
>
> We're using Neo4j as our underlying database, though we have no strong
> attachment to it.
>
> Are there roadmap plans to supporting nesting loops?   (ie, a repeat under
> a repeat)
>
>
> On 2/15/18, 10:15 AM, "Stephen Mallette"  wrote:
>
> Cool. I flip/flop back and forth about having better support for
> general
> predicates (like text and geo) - seems like this would be a argument in
> favor of adding such things to resolve this problem of having to write
> server side DSL code. if done right it might save graph providers from
> having to write their on extensions to GLVs .
>
> Out of curiosity, what graph database are you using?
>
> On Thu, Feb 15, 2018 at 11:39 AM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > >Can you talk about what those custom steps do? Do you also have
> custom
> >  >   TraversalStrategies which interact with them?
> >
> > We do not have any custom TraversalStrategies yet.
> >
> > We do have custom predicates, though not many...  Mostly string
> operations
> > (textContains, textRegex).
> >
> > Most of our custom steps can be implemented as plain Gremlin,
> however,
> > we've found that because we know the shape of our graphs (it starts
> with an
> > explicit tree structure, with other edges layered on top), we can
> write
> > some steps more efficiently, or just more easily, as direct
> TinkerPop java
> > Vertex/Edge operations.
> >
> > One of our custom steps, however, is a work-around to the fact that
> the
> > NESTED_LOOP traversal requirement, still, cannot be met.
> >
> >
> >
> > On 2/15/18, 9:10 AM, "Stephen Mallette" 
> wrote:
> >
> > >  Do you expect to *NOT* support server-side DSLs in the future
> (even
> > as
> > Bytecode)?
> >
> > I think that's it's a bit early to say that definitively, but all
> > community
> > discussion thus far has pointed in the direction of keeping DSLs
> a
> > client-side construct, so I'd expect that we would not do much
> work to
> > support them (i.e. make them easier to implement, write
> documentation,
> > discuss them as best practices, etc) in an official capacity for
> > end-users.
> >
> > There are a lot of reasons for that (some technical and some
> not), but
> > I
> > think that one of the biggest ones I tend to think of the most
> these
> > days
> > is that we are seeing more and more TinkerPop-enabled. graph
> systems
> > that
> > are server oriented (e.g. DSE Graph) or simply a managed service
> (e.g
> > CosmosDB) which don't allow a lot of control of what happens on
> the
> > server.
> > They just accept bytecode/scripts, process them and send results.
> > Embracing
> > that model from the TinkerPop perspective vastly simplifies the
> > interfaces
> > we need to expose to Graph System Providers who want to be
> > TinkerPop-enabled and vastly reduces the surface area of
> interaction
> > that
> > users have to face to use Gremlin. When I consider embracing that
> > model in
> > relation to DSLs, I tend to see DSLs as lightweight client-only
> > implementations that don't introduce headaches to the Graph
> Systems for
> > which TinkerPop doesn't really offer much answer (e.g how do i
> allow
> > users
> > to deploy code to the servers, can i allow custom steps to be
> deployed
> > securely, what about serialization of these custom steps?). I
> think
> > we'd
> > want to take those issues off the table.
> >
> > >  We do have a handful of custom steps
> >
> > That's interesting. Again, I think this puts you in a different
> > category
> > that goes beyond what DSLs were intended for. Going down this
> route
> > makes
> > for highly advanced usage. Custom steps on the server would mean
> a GLV
> > would need to be extended to support those steps which ties into
> > bytecode
> > serialization for both client and server. Complicated stuff
> without
> > use of
> > scripts (which is why you are using them i gather).
> >
> > Can you talk about what those custom steps do? Do you also have
> custom
> > TraversalStrategies which interact with them?
> >
> >
> > On Thu, Feb 15, 2018 at 10:17 AM, Moore, Branden James <
> > 

Re: [EXTERNAL] Re: Anonymous traversals with @GremlinDSL and Gremlin-Groovy Script Engine

[Moore, Branden James]

 >   Out of curiosity, what graph database are you using?
   
We're using Neo4j as our underlying database, though we have no strong 
attachment to it.

Are there roadmap plans to supporting nesting loops?   (ie, a repeat under a 
repeat)


On 2/15/18, 10:15 AM, "Stephen Mallette"  wrote:

Cool. I flip/flop back and forth about having better support for general
predicates (like text and geo) - seems like this would be a argument in
favor of adding such things to resolve this problem of having to write
server side DSL code. if done right it might save graph providers from
having to write their on extensions to GLVs .

Out of curiosity, what graph database are you using?

On Thu, Feb 15, 2018 at 11:39 AM, Moore, Branden James 
wrote:

> >Can you talk about what those custom steps do? Do you also have 
custom
>  >   TraversalStrategies which interact with them?
>
> We do not have any custom TraversalStrategies yet.
>
> We do have custom predicates, though not many...  Mostly string operations
> (textContains, textRegex).
>
> Most of our custom steps can be implemented as plain Gremlin, however,
> we've found that because we know the shape of our graphs (it starts with 
an
> explicit tree structure, with other edges layered on top), we can write
> some steps more efficiently, or just more easily, as direct TinkerPop java
> Vertex/Edge operations.
>
> One of our custom steps, however, is a work-around to the fact that the
> NESTED_LOOP traversal requirement, still, cannot be met.
>
>
>
> On 2/15/18, 9:10 AM, "Stephen Mallette"  wrote:
>
> >  Do you expect to *NOT* support server-side DSLs in the future (even
> as
> Bytecode)?
>
> I think that's it's a bit early to say that definitively, but all
> community
> discussion thus far has pointed in the direction of keeping DSLs a
> client-side construct, so I'd expect that we would not do much work to
> support them (i.e. make them easier to implement, write documentation,
> discuss them as best practices, etc) in an official capacity for
> end-users.
>
> There are a lot of reasons for that (some technical and some not), but
> I
> think that one of the biggest ones I tend to think of the most these
> days
> is that we are seeing more and more TinkerPop-enabled. graph systems
> that
> are server oriented (e.g. DSE Graph) or simply a managed service (e.g
> CosmosDB) which don't allow a lot of control of what happens on the
> server.
> They just accept bytecode/scripts, process them and send results.
> Embracing
> that model from the TinkerPop perspective vastly simplifies the
> interfaces
> we need to expose to Graph System Providers who want to be
> TinkerPop-enabled and vastly reduces the surface area of interaction
> that
> users have to face to use Gremlin. When I consider embracing that
> model in
> relation to DSLs, I tend to see DSLs as lightweight client-only
> implementations that don't introduce headaches to the Graph Systems 
for
> which TinkerPop doesn't really offer much answer (e.g how do i allow
> users
> to deploy code to the servers, can i allow custom steps to be deployed
> securely, what about serialization of these custom steps?). I think
> we'd
> want to take those issues off the table.
>
> >  We do have a handful of custom steps
>
> That's interesting. Again, I think this puts you in a different
> category
> that goes beyond what DSLs were intended for. Going down this route
> makes
> for highly advanced usage. Custom steps on the server would mean a GLV
> would need to be extended to support those steps which ties into
> bytecode
> serialization for both client and server. Complicated stuff without
> use of
> scripts (which is why you are using them i gather).
>
> Can you talk about what those custom steps do? Do you also have custom
> TraversalStrategies which interact with them?
>
>
> On Thu, Feb 15, 2018 at 10:17 AM, Moore, Branden James <
> bjm...@sandia.gov>
> wrote:
>
> > Now that python-gremlin is mature enough to use and extend, I'm
> working to
> > migrate our environment to a fully session-less, bytecode-based
> > environment.  However, we currently have significant amounts of
> "legacy"
> > groovy/gremlin hanging around.  Until all of that can be migrated,
> we still
> > need to use the older model.
> >
> > We do have a handful of custom steps that are not implemented as
> > combinations of existing 

[jira] [Updated] (TINKERPOP-1647) Create a Stateful interface for steps that have internal state.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1647:

Issue Type: Improvement  (was: Bug)

> Create a Stateful interface for steps that have internal state.
> ---
>
> Key: TINKERPOP-1647
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1647
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.4
>Reporter: Marko A. Rodriguez
>Priority: Major
>
> Right now, both {{DedupGlobalStep}} and {{TimeLimitStep}} are "stateful 
> steps" and because of this, shouldn't be decomposed by strategies such as 
> {{RepeatUnrollStrategy}}. Make a generalizing interface so search traversals 
> for such stateful steps is easy an not error prone.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Closed] (TINKERPOP-1781) Traversal admin addStep does not update bytecode

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1781.
---
Resolution: Won't Do

Given the last comment and my understanding of things, I think we should close 
this one. I don't think we're going down the path of client side strategy 
application. Feel free to re-open if there are some different thoughts here.

> Traversal admin addStep does not update bytecode
> 
>
> Key: TINKERPOP-1781
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1781
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.0, 3.2.6
>Reporter: Ted Wilmes
>Priority: Major
>
> Right now bytecode is constructed at traversal construction time and is not 
> updated post-construction when traversal rewriting happens via strategies. 
> This works fine in most cases because the traversal is locked post-strategy 
> application and will be executed, not serialized out for execution somewhere 
> else. 
> There are issues when trying to apply client side, pre-serialization 
> traversal rewriting (a kind of client-side traversal strategy outside of the 
> usual strategy flow). Since a direct call to {{addStep}} circumvents the 
> bytecode construction, the bytecode diverges from the rewritten traversal.
> {code}
> gremlin> traversal = g.V().out();null
> ==>null
> gremlin> traversal.getSteps()
> ==>GraphStep(vertex,[])
> ==>VertexStep(OUT,vertex)
> gremlin> traversal.getBytecode()
> ==>[[], [V(), out()]]
> gremlin> TraversalHelper.insertAfterStep(new CountGlobalStep(traversal), 
> traversal.getSteps()[1], traversal.asAdmin())
> ==>null
> gremlin> traversal.getSteps()
> ==>GraphStep(vertex,[])
> ==>VertexStep(OUT,vertex)
> ==>CountGlobalStep
> gremlin> traversal.getBytecode()
> ==>[[], [V(), out()]]
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)