[jira] [Commented] (TINKERPOP-1985) Update position on bulk loading
[
https://issues.apache.org/jira/browse/TINKERPOP-1985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519851#comment-16519851
]
ASF GitHub Bot commented on TINKERPOP-1985:
---
GitHub user spmallette opened a pull request:
https://github.com/apache/tinkerpop/pull/884
TINKERPOP-1985 Changing position on bulk import/export
https://issues.apache.org/jira/browse/TINKERPOP-1985
Deprecated `BulkLoaderVertexProgram` and `BulkDumperVertexProgram`. BLVP is
not replaced, but BDVP has been renamed to `CloneVertexProgram` which is more
aptly named for what it does. Modified docs to discuss all these changes.
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1985
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/884.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #884
commit fe250834684202c0fbd947da816d172b07d5c9d4
Author: Stephen Mallette
Date: 2018-06-21T19:11:36Z
TINKERPOP-1985 Changing position on bulk import/export
Deprecated BulkLoaderVertexProgram and BulkDumperVertexProgram. BLVP is not
replaced, but BDVP has been renamed to CloneVertexProgram which is more aptly
named for what it does. Modified docs to discuss all these changes.
> Update position on bulk loading
> ---
>
> Key: TINKERPOP-1985
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1985
> Project: TinkerPop
> Issue Type: Improvement
> Components: documentation
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Labels: deprecation
>
> There was some discussion on TinkerPop's position on bulk loading on the dev
> list:
> https://lists.apache.org/thread.html/1f91d87d2af942497e2c0ca4c3d535752b21a45a945e7750e912e982@%3Cdev.tinkerpop.apache.org%3E
> Basically, we will rely on graph providers to supply their own bulk loaders
> and will not promote generic TinkerPop methods for doing so. We will keep
> {{BulkDumperVertexProgram}} so that providers can rely on that bulk loading
> infrastructure if they like. {{BulkLoaderVertexProgram}} can be deprecated.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #884: TINKERPOP-1985 Changing position on bulk import...
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/884 TINKERPOP-1985 Changing position on bulk import/export https://issues.apache.org/jira/browse/TINKERPOP-1985 Deprecated `BulkLoaderVertexProgram` and `BulkDumperVertexProgram`. BLVP is not replaced, but BDVP has been renamed to `CloneVertexProgram` which is more aptly named for what it does. Modified docs to discuss all these changes. All tests pass with `docker/build.sh -t -n -i` VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1985 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/884.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #884 commit fe250834684202c0fbd947da816d172b07d5c9d4 Author: Stephen Mallette Date: 2018-06-21T19:11:36Z TINKERPOP-1985 Changing position on bulk import/export Deprecated BulkLoaderVertexProgram and BulkDumperVertexProgram. BLVP is not replaced, but BDVP has been renamed to CloneVertexProgram which is more aptly named for what it does. Modified docs to discuss all these changes. ---
[jira] [Commented] (TINKERPOP-1990) Add a shortestPath() step
[
https://issues.apache.org/jira/browse/TINKERPOP-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519792#comment-16519792
]
ASF GitHub Bot commented on TINKERPOP-1990:
---
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/882
I will try to find some time to do TINKERPOP-1991 and see what is involved.
If it's a mess then maybe we don't try to shove TINKERPOP-1991 into 3.4.0 and
await 3.5.0 then just merge `shortestPath()` and `connectedComponent()` for
3.4.0. I'd say that if we get stuck without TINKERPOP-1991 we probably
shouldn't add anymore algorithms until 3.5.0 so as to not further pollute the
core Gremlin space. thinky think
> Add a shortestPath() step
> -
>
> Key: TINKERPOP-1990
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1990
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Implement {{ShortestPathVertexProgram}} and a {{shortestPath()}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #882: TINKERPOP-1990 Add a shortestPath() step
Github user spmallette commented on the issue: https://github.com/apache/tinkerpop/pull/882 I will try to find some time to do TINKERPOP-1991 and see what is involved. If it's a mess then maybe we don't try to shove TINKERPOP-1991 into 3.4.0 and await 3.5.0 then just merge `shortestPath()` and `connectedComponent()` for 3.4.0. I'd say that if we get stuck without TINKERPOP-1991 we probably shouldn't add anymore algorithms until 3.5.0 so as to not further pollute the core Gremlin space. thinky think ---
[GitHub] tinkerpop pull request #883: TINKERPOP-1864 Run python glv tests on GraphSON...
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/883 TINKERPOP-1864 Run python glv tests on GraphSON 2.0 and 3.0 https://issues.apache.org/jira/browse/TINKERPOP-1864 There was about a 10 second time increase for adding the additional test execution option. Seems worthwhile. Builds with `mvn clean install -pl gremlin-python` VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1864 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/883.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #883 commit 6bd3199967608b8f1fd66ac1c72ccbbce7b76418 Author: Stephen Mallette Date: 2018-06-21T21:24:58Z TINKERPOP-1864 Run python glv tests on GraphSON 2.0 and 3.0 There was about a 10 second time increase for adding the additional test execution option. Seems worthwhile. ---
[jira] [Commented] (TINKERPOP-1990) Add a shortestPath() step
[
https://issues.apache.org/jira/browse/TINKERPOP-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519740#comment-16519740
]
ASF GitHub Bot commented on TINKERPOP-1990:
---
GitHub user dkuppitz opened a pull request:
https://github.com/apache/tinkerpop/pull/882
TINKERPOP-1990 Add a shortestPath() step
Implemented `ShortestPathVertexProgram` and `ShortestPathVertexProgramStep`.
`docker/build.sh -t -i -n -d` passed.
VOTE: +1
I can wait for TINKERPOP-1991 before I merge it or merge it into `master/`
now and then go from there with TINKERPOP-1991, I don't care.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1990
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/882.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #882
commit 8a43eaadfdb4ab662f955cc4a1cde6bf5739f7db
Author: Daniel Kuppitz
Date: 2018-05-23T12:46:34Z
TINKERPOP-1990 Implemented `ShortestPathVertexProgram` and
`ShortestPathVertexProgramStep`.
> Add a shortestPath() step
> -
>
> Key: TINKERPOP-1990
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1990
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> Implement {{ShortestPathVertexProgram}} and a {{shortestPath()}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #882: TINKERPOP-1990 Add a shortestPath() step
GitHub user dkuppitz opened a pull request: https://github.com/apache/tinkerpop/pull/882 TINKERPOP-1990 Add a shortestPath() step Implemented `ShortestPathVertexProgram` and `ShortestPathVertexProgramStep`. `docker/build.sh -t -i -n -d` passed. VOTE: +1 I can wait for TINKERPOP-1991 before I merge it or merge it into `master/` now and then go from there with TINKERPOP-1991, I don't care. You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1990 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/882.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #882 commit 8a43eaadfdb4ab662f955cc4a1cde6bf5739f7db Author: Daniel Kuppitz Date: 2018-05-23T12:46:34Z TINKERPOP-1990 Implemented `ShortestPathVertexProgram` and `ShortestPathVertexProgramStep`. ---
Re: [DISCUSS] text predicates
> Also, wouldn't you need to configure a serializer for
'DseGraph.searchType'?
that's the nice part of with() - internally that falls into a standard Map
in bytecode and no serialization hassles. it still leaves the graph
provider to expose a "DseGraph" type of class, but at least there is
nothing to configure anywhere
> Then all that's left is fuzzy. I don't have an opinion on that yet.
Maybe it's more Search enums?
could be. or with() is the catch all case that providers can use for
"everything else" they can come up withfor now
On Thu, Jun 21, 2018 at 3:52 PM Robert Dale wrote:
> No, that makes it non-portable, provider-specific. That is, I can't
> cut-n-paste that from one graph db to the next. Also, wouldn't you need to
> configure a serializer for 'DseGraph.searchType'?
>
> I think we can start with a small, simple set.
>
> startsWith(String)
> startsWith(Search,String)
> contains(String)
> contains(Search, String)
> regex(String)
> regex(Search, String)
>
> Each takes Search, String. Where Search is an enum of String (default),
> Text (tokenized). String is the search term.
>
> The regex syntax may be provider-specific, but the traversal would be
> portable. If the provider doesn't override the step/predicate then it would
> use the default implementation.
>
> Then all that's left is fuzzy. I don't have an opinion on that yet. Maybe
> it's more Search enums?
>
> Robert Dale
>
>
> On Thu, Jun 21, 2018 at 3:04 PM Stephen Mallette
> wrote:
>
> > Just thinking out loud here, but i wonder if we could keep our predicate
> > list more or less as-is, but then use with() to modulate a has() to be
> > provider specific:
> >
> > g.V().
> >has('longText',eq("a.*").
> > with(DseGraph.searchType, tokenRegex)
> >
> > In other words, this would be the standard way that users would inform
> > graph providers to handle special text search types. The upside is that
> >
> > 1. graph providers no longer have to hassle with serialization at all to
> > implement this (which means users don't need special configuration of
> their
> > servers/drivers).
> > 2. we have a common way that all graph providers can take advantage of
> and
> > thus users have one method for writing their gremlin (albeit with
> different
> > with() and search syntax).
> > 3. we can make this part of our reference implementation i think pretty
> > easily for TinkerGraph with some basic java regex stuff.
> > 4. stays backward compatible with existing graph provider predicates
> >
> > good idea?
> >
> >
> >
> > On Mon, Jun 11, 2018 at 9:12 AM Stephen Mallette
> > wrote:
> >
> > > I found a CosmosDB issue on github calling for support of text
> predicates
> > >
> > > https://github.com/Azure/azure-documentdb-dotnet/issues/473
> > >
> > > and it conveniently listed the text predicates for a number of
> different
> > > graphs, so it made the job of compiling these pretty easy.
> > >
> > > DSE Graph (tokenized search is for long multi-sentence type properties)
> > > + eq/neq
> > > + prefix
> > > + regex
> > > + token
> > > + tokenPrefix
> > > + tokenRegex
> > > + phrase
> > > + fuzzy
> > > + tokenFuzzy
> > >
> > >
> > >
> >
> https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/graph/using/useSearchIndexes.html
> > >
> > > JanusGraph
> > > + textContains
> > > + textContainsPrefix
> > > + textContainsRegex
> > > + textContainsFuzzy
> > > + eq/neq
> > > + textPrefix
> > > + textRegex
> > > + textFuzzy
> > >
> > > http://docs.janusgraph.org/latest/index-parameters.html#text-search
> > >
> > > Neo4j/Cypher
> > > + STARTS WITH
> > > + ENDS WITH
> > > + CONTAINS
> > >
> > >
> >
> http://www.jexp.de/blog/html/full-text-and-spatial-search-in-neo4j-3.html
> > >
> > > OrientDB - basically just lucene syntax
> > > + LUCENE
> > >
> > > https://orientdb.com/docs/last/Full-Text-Index.html
> > >
> > > So - that's the list as best I can determine. JanusGraph and DSE Graph
> > > have the most complex set of expressions it seems. Neo4j/Cypher has the
> > > easiest developer friendly looking set that probably covers most of the
> > > questions we get out in the community. OrientDB gets vendor specific in
> > > what they do. Did I leave any out - please update this thread if I
> did.
> > >
> > > Not sure what we do with that now, but that's what is out there.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
>
Re: [DISCUSS] text predicates
No, that makes it non-portable, provider-specific. That is, I can't
cut-n-paste that from one graph db to the next. Also, wouldn't you need to
configure a serializer for 'DseGraph.searchType'?
I think we can start with a small, simple set.
startsWith(String)
startsWith(Search,String)
contains(String)
contains(Search, String)
regex(String)
regex(Search, String)
Each takes Search, String. Where Search is an enum of String (default),
Text (tokenized). String is the search term.
The regex syntax may be provider-specific, but the traversal would be
portable. If the provider doesn't override the step/predicate then it would
use the default implementation.
Then all that's left is fuzzy. I don't have an opinion on that yet. Maybe
it's more Search enums?
Robert Dale
On Thu, Jun 21, 2018 at 3:04 PM Stephen Mallette
wrote:
> Just thinking out loud here, but i wonder if we could keep our predicate
> list more or less as-is, but then use with() to modulate a has() to be
> provider specific:
>
> g.V().
>has('longText',eq("a.*").
> with(DseGraph.searchType, tokenRegex)
>
> In other words, this would be the standard way that users would inform
> graph providers to handle special text search types. The upside is that
>
> 1. graph providers no longer have to hassle with serialization at all to
> implement this (which means users don't need special configuration of their
> servers/drivers).
> 2. we have a common way that all graph providers can take advantage of and
> thus users have one method for writing their gremlin (albeit with different
> with() and search syntax).
> 3. we can make this part of our reference implementation i think pretty
> easily for TinkerGraph with some basic java regex stuff.
> 4. stays backward compatible with existing graph provider predicates
>
> good idea?
>
>
>
> On Mon, Jun 11, 2018 at 9:12 AM Stephen Mallette
> wrote:
>
> > I found a CosmosDB issue on github calling for support of text predicates
> >
> > https://github.com/Azure/azure-documentdb-dotnet/issues/473
> >
> > and it conveniently listed the text predicates for a number of different
> > graphs, so it made the job of compiling these pretty easy.
> >
> > DSE Graph (tokenized search is for long multi-sentence type properties)
> > + eq/neq
> > + prefix
> > + regex
> > + token
> > + tokenPrefix
> > + tokenRegex
> > + phrase
> > + fuzzy
> > + tokenFuzzy
> >
> >
> >
> https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/graph/using/useSearchIndexes.html
> >
> > JanusGraph
> > + textContains
> > + textContainsPrefix
> > + textContainsRegex
> > + textContainsFuzzy
> > + eq/neq
> > + textPrefix
> > + textRegex
> > + textFuzzy
> >
> > http://docs.janusgraph.org/latest/index-parameters.html#text-search
> >
> > Neo4j/Cypher
> > + STARTS WITH
> > + ENDS WITH
> > + CONTAINS
> >
> >
> http://www.jexp.de/blog/html/full-text-and-spatial-search-in-neo4j-3.html
> >
> > OrientDB - basically just lucene syntax
> > + LUCENE
> >
> > https://orientdb.com/docs/last/Full-Text-Index.html
> >
> > So - that's the list as best I can determine. JanusGraph and DSE Graph
> > have the most complex set of expressions it seems. Neo4j/Cypher has the
> > easiest developer friendly looking set that probably covers most of the
> > questions we get out in the community. OrientDB gets vendor specific in
> > what they do. Did I leave any out - please update this thread if I did.
> >
> > Not sure what we do with that now, but that's what is out there.
> >
> >
> >
> >
> >
> >
> >
> >
>
Re: [DISCUSS] text predicates
Just thinking out loud here, but i wonder if we could keep our predicate
list more or less as-is, but then use with() to modulate a has() to be
provider specific:
g.V().
has('longText',eq("a.*").
with(DseGraph.searchType, tokenRegex)
In other words, this would be the standard way that users would inform
graph providers to handle special text search types. The upside is that
1. graph providers no longer have to hassle with serialization at all to
implement this (which means users don't need special configuration of their
servers/drivers).
2. we have a common way that all graph providers can take advantage of and
thus users have one method for writing their gremlin (albeit with different
with() and search syntax).
3. we can make this part of our reference implementation i think pretty
easily for TinkerGraph with some basic java regex stuff.
4. stays backward compatible with existing graph provider predicates
good idea?
On Mon, Jun 11, 2018 at 9:12 AM Stephen Mallette
wrote:
> I found a CosmosDB issue on github calling for support of text predicates
>
> https://github.com/Azure/azure-documentdb-dotnet/issues/473
>
> and it conveniently listed the text predicates for a number of different
> graphs, so it made the job of compiling these pretty easy.
>
> DSE Graph (tokenized search is for long multi-sentence type properties)
> + eq/neq
> + prefix
> + regex
> + token
> + tokenPrefix
> + tokenRegex
> + phrase
> + fuzzy
> + tokenFuzzy
>
>
> https://docs.datastax.com/en/dse/6.0/dse-dev/datastax_enterprise/graph/using/useSearchIndexes.html
>
> JanusGraph
> + textContains
> + textContainsPrefix
> + textContainsRegex
> + textContainsFuzzy
> + eq/neq
> + textPrefix
> + textRegex
> + textFuzzy
>
> http://docs.janusgraph.org/latest/index-parameters.html#text-search
>
> Neo4j/Cypher
> + STARTS WITH
> + ENDS WITH
> + CONTAINS
>
> http://www.jexp.de/blog/html/full-text-and-spatial-search-in-neo4j-3.html
>
> OrientDB - basically just lucene syntax
> + LUCENE
>
> https://orientdb.com/docs/last/Full-Text-Index.html
>
> So - that's the list as best I can determine. JanusGraph and DSE Graph
> have the most complex set of expressions it seems. Neo4j/Cypher has the
> easiest developer friendly looking set that probably covers most of the
> questions we get out in the community. OrientDB gets vendor specific in
> what they do. Did I leave any out - please update this thread if I did.
>
> Not sure what we do with that now, but that's what is out there.
>
>
>
>
>
>
>
>
[jira] [Created] (TINKERPOP-1991) Algorithm DSL
stephen mallette created TINKERPOP-1991:
---
Summary: Algorithm DSL
Key: TINKERPOP-1991
URL: https://issues.apache.org/jira/browse/TINKERPOP-1991
Project: TinkerPop
Issue Type: Improvement
Components: process
Affects Versions: 3.3.3
Reporter: stephen mallette
Assignee: stephen mallette
Create an Algorithm DSL so that we don't pollute gremlin-core with too many of
those types of steps (e.g. {{pageRank()}}, {{peerPressure()}}, etc). Will need
to deprecate the current algorithm steps in core as part of this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [DISCUSS] Algorithm DSL
Create an issue in JIRA for this: https://issues.apache.org/jira/browse/TINKERPOP-1991 On Fri, Jun 1, 2018 at 4:35 PM Stephen Mallette wrote: > Right now we have pageRank() and peerPressure() just sorta hanging out in > our core traversal API, but they really don't fit well there. Plus, as we > add more of those types of steps we risk polluting the core API further. I > think that these steps were originally placed there as a bit of an > experiment (and out of convenience) and the intention was to eventually > move them somewhere more permanent. > > I think we should pull these methods and other ones that follow into a > special DSL designed to house these things. Not exactly sure what that will > look like at the moment, but I feel like we should build something more > concrete than what is produced by the more user oriented annotation-based > DSL system. I think we would look to try to deprecate pageRank() and > peerPressure() for 3.4.0 and remove them completely at some future release > where breaking changes were allowed. > > Not sure what kind of hell awaits in the GLVs if we do thisprobably > won't be pretty. > > Any thoughts or concerns? >
[jira] [Created] (TINKERPOP-1990) Add a shortestPath() step
Daniel Kuppitz created TINKERPOP-1990:
-
Summary: Add a shortestPath() step
Key: TINKERPOP-1990
URL: https://issues.apache.org/jira/browse/TINKERPOP-1990
Project: TinkerPop
Issue Type: Improvement
Components: process
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz
Implement {{ShortestPathVertexProgram}} and a {{shortestPath()}} step.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (TINKERPOP-967) Support nested-repeat() structures
[
https://issues.apache.org/jira/browse/TINKERPOP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519611#comment-16519611
]
ASF GitHub Bot commented on TINKERPOP-967:
--
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/876
Some more notes from Marko (i haven't had a chance to let them sink in
myself, just pasting them here):
```text
times(a,2) == loops(a,eq(2))
```
the idea being, you might want to check on the loop count of an outer loop
within an inner loop and vice versa. Basically, you are trying to solve:
```text
for(i=0;i<10) { for(j=0;j<10) if(i == x) …. } ….
```
the point being, you want to be able to check for `i` and `j` counters not
just at the loop check point but anywhere in the respective body.
And note that naming `repeat()`s is not the same as naming the
`repeat()`-step. It isn’t a step label……… though, some thinking on that might
be worth it. In essence `repeat(‘a’,…) != repeat(…).as(‘a’)`
the ‘a’ in the first is for the loop stack, not for the step label….but
again, perhaps there is a reason to unite the two concepts. Though if done so,
a new syntax would be introduced which would add an “irregularity” to Gremlin
> Support nested-repeat() structures
> --
>
> Key: TINKERPOP-967
> URL: https://issues.apache.org/jira/browse/TINKERPOP-967
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Major
>
> All the internal plumbing is staged for this to happen, we just haven't gone
> all the way. In short, a {{NESTED_LOOP}} traverser has an internal
> {{loopStack}} where {{repeat(repeat())}} will have a {{loopStack}} of two.
> The {{it.loops()}} checks of the internal repeat will always check the top of
> the stack and when its done repeating will delete its counter off the top of
> the stack.
> [~dkuppitz]'s work on {{LoopStep}} will be backwards compatible. In
> {{RepeatStep}} we will support:
> {code}
> repeat('a',out('knows').repeat('b',out('parent')))
> {code}
> and thus, things like {{loops('a')}} as well as {{times('a',2)}}. Note that
> naming the loop stack will be a super rare case as most people will just
> assume standard nested looping semantics with a push/pop stack.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #876: TINKERPOP-967 Support nested-repeat() structures
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/876
Some more notes from Marko (i haven't had a chance to let them sink in
myself, just pasting them here):
```text
times(a,2) == loops(a,eq(2))
```
the idea being, you might want to check on the loop count of an outer loop
within an inner loop and vice versa. Basically, you are trying to solve:
```text
for(i=0;i<10) { for(j=0;j<10) if(i == x) â¦. } â¦.
```
the point being, you want to be able to check for `i` and `j` counters not
just at the loop check point but anywhere in the respective body.
And note that naming `repeat()`s is not the same as naming the
`repeat()`-step. It isnât a step labelâ¦â¦â¦ though, some thinking on that
might be worth it. In essence `repeat(âaâ,â¦) != repeat(â¦).as(âaâ)`
the âaâ in the first is for the loop stack, not for the step
labelâ¦.but again, perhaps there is a reason to unite the two concepts. Though
if done so, a new syntax would be introduced which would add an
âirregularityâ to Gremlin
---
[jira] [Commented] (TINKERPOP-1365) Log the seed used to initialize Random in tests
[
https://issues.apache.org/jira/browse/TINKERPOP-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519422#comment-16519422
]
ASF GitHub Bot commented on TINKERPOP-1365:
---
GitHub user spmallette opened a pull request:
https://github.com/apache/tinkerpop/pull/881
TINKERPOP-1365 Refactored use of Random in tests
Each test suite now uses the same instance of Random which prints the seed
given to it so that if there is a failure, we can easily try to recreate it by
taking the seed and passing it in as a system property with -DtestSeed. The
output logs as:
```text
[INFO] org.apache.tinkerpop.gremlin.TestHelper - *** THE RANDOM TEST SEED
IS 1529585621517 ***
```
I didn't replace all of the old use of `Random` - there were a couple
places where I felt like a true `Random` was still necessary and just left it
alone despite the horror it might cause. Going forward we'll want to use the
`TestHelper.RANDOM` whenever possible (or, better, just not use a `Random` at
all).
All tests pass with `docker/build.sh -t -n -i`
VOTE +1
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/apache/tinkerpop TINKERPOP-1365
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/tinkerpop/pull/881.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #881
commit 12d9c793dda7b4cd98122756331916362055f389
Author: Stephen Mallette
Date: 2018-06-21T14:11:58Z
TINKERPOP-1365 Refactored use of Random in tests
Each test suite now uses the same instance of Random which prints the seed
given to it so that if there is a failure, we can easily try to recreate it by
taking the seed and passing it in as a system property with -DtestSeed.
> Log the seed used to initialize Random in tests
> ---
>
> Key: TINKERPOP-1365
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1365
> Project: TinkerPop
> Issue Type: Improvement
> Components: test-suite
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Jason Plurad
>Priority: Major
>
> {{HadoopGraphProvider}} and {{SparkHadoopGraphProvider}} use
> {{RANDOM.nextBoolean()}} in an attempt to get coverage over different load
> scenarios. In practice, this ends up causing nondeterministic execution of
> the test suite, which can mask real errors lingering in the code or test code.
> See TINKERPOP-1360
> Logging the seed used for these tests will allow us to re-run the test in the
> same way on failure.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop pull request #881: TINKERPOP-1365 Refactored use of Random in test...
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/881 TINKERPOP-1365 Refactored use of Random in tests Each test suite now uses the same instance of Random which prints the seed given to it so that if there is a failure, we can easily try to recreate it by taking the seed and passing it in as a system property with -DtestSeed. The output logs as: ```text [INFO] org.apache.tinkerpop.gremlin.TestHelper - *** THE RANDOM TEST SEED IS 1529585621517 *** ``` I didn't replace all of the old use of `Random` - there were a couple places where I felt like a true `Random` was still necessary and just left it alone despite the horror it might cause. Going forward we'll want to use the `TestHelper.RANDOM` whenever possible (or, better, just not use a `Random` at all). All tests pass with `docker/build.sh -t -n -i` VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1365 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/881.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #881 commit 12d9c793dda7b4cd98122756331916362055f389 Author: Stephen Mallette Date: 2018-06-21T14:11:58Z TINKERPOP-1365 Refactored use of Random in tests Each test suite now uses the same instance of Random which prints the seed given to it so that if there is a failure, we can easily try to recreate it by taking the seed and passing it in as a system property with -DtestSeed. ---
[jira] [Updated] (TINKERPOP-1365) Log the seed used to initialize Random in tests
[ https://issues.apache.org/jira/browse/TINKERPOP-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1365: Summary: Log the seed used to initialize Random in tests (was: Eliminate Random.nextBoolean() usage in tests) > Log the seed used to initialize Random in tests > --- > > Key: TINKERPOP-1365 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1365 > Project: TinkerPop > Issue Type: Improvement > Components: test-suite >Affects Versions: 3.2.0-incubating, 3.1.2-incubating >Reporter: Jason Plurad >Priority: Major > > HadoopGraphProvider and SparkHadoopGraphProvider use RANDOM.nextBoolean() in > an attempt to get coverage over different load scenarios. In practice, this > ends up causing nondeterministic execution of the test suite, which can mask > real errors lingering in the code or test code. > See https://issues.apache.org/jira/browse/TINKERPOP-1360 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
How to create Query to find Vertex and its outs
Hi, I'm new about Java gremlin. I need an help on gremlin over OrientDB. This is my scenario: On my graph I have 2 Vertex classes, type A and type B. Let A is a Vertex of type A and it is linked to 0 or more Vertices of type B. So now I need to find both any A (filtering by a field of A) and the list of all B vertices B linked to A. Is possible, using GremlinPipeline to have this response? Currently I execute the query in 2 steps: 1- Find the list of A (filtering by a field) 2- For each A I search the list (if any) of B linked to A In this case the query needs 9 seconds if I have a lot of B linked to some A. Can somebody help me? Gianluca
[jira] [Commented] (TINKERPOP-967) Support nested-repeat() structures
[
https://issues.apache.org/jira/browse/TINKERPOP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16519114#comment-16519114
]
ASF GitHub Bot commented on TINKERPOP-967:
--
Github user GCHQResearcher1337 commented on the issue:
https://github.com/apache/tinkerpop/pull/876
@spamallete I think I steered away from that because I initially
misunderstood what marko meant - as you pointed out the plumbing (`incrLoops`
taking a `stepLabel`) for nested repeats is already there, but I didn't find
any plumbing had been done for this (neither `times()` nor `loop()` can take a
`stepLabel`) so I thought that the 'work on `LoopStep`' had been abandoned.
Re-reading this I think I see what is involved and can implement this -
both `TimesModulating` and `LoopStep` as well as the `loops()` method of a
traverser need to be able to take a stepLabel. We would need to maintain a
separate user-defined stepLabel that could be accessed.
I can see why `loops('a')` could be helpful, but I don't know why you would
want to do `times('a',2)`. Could you please provide an example of this?
PS Hi Marko! Thanks for Gremlin!
> Support nested-repeat() structures
> --
>
> Key: TINKERPOP-967
> URL: https://issues.apache.org/jira/browse/TINKERPOP-967
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Major
>
> All the internal plumbing is staged for this to happen, we just haven't gone
> all the way. In short, a {{NESTED_LOOP}} traverser has an internal
> {{loopStack}} where {{repeat(repeat())}} will have a {{loopStack}} of two.
> The {{it.loops()}} checks of the internal repeat will always check the top of
> the stack and when its done repeating will delete its counter off the top of
> the stack.
> [~dkuppitz]'s work on {{LoopStep}} will be backwards compatible. In
> {{RepeatStep}} we will support:
> {code}
> repeat('a',out('knows').repeat('b',out('parent')))
> {code}
> and thus, things like {{loops('a')}} as well as {{times('a',2)}}. Note that
> naming the loop stack will be a super rare case as most people will just
> assume standard nested looping semantics with a push/pop stack.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[GitHub] tinkerpop issue #876: TINKERPOP-967 Support nested-repeat() structures
Github user GCHQResearcher1337 commented on the issue:
https://github.com/apache/tinkerpop/pull/876
@spamallete I think I steered away from that because I initially
misunderstood what marko meant - as you pointed out the plumbing (`incrLoops`
taking a `stepLabel`) for nested repeats is already there, but I didn't find
any plumbing had been done for this (neither `times()` nor `loop()` can take a
`stepLabel`) so I thought that the 'work on `LoopStep`' had been abandoned.
Re-reading this I think I see what is involved and can implement this -
both `TimesModulating` and `LoopStep` as well as the `loops()` method of a
traverser need to be able to take a stepLabel. We would need to maintain a
separate user-defined stepLabel that could be accessed.
I can see why `loops('a')` could be helpful, but I don't know why you would
want to do `times('a',2)`. Could you please provide an example of this?
PS Hi Marko! Thanks for Gremlin!
---
[GitHub] tinkerpop issue #880: TINKERPOP-1989 Enforce order of plugin load in Gremlin...
Github user jorgebay commented on the issue: https://github.com/apache/tinkerpop/pull/880 lgtm, VOTE +1 ---
[jira] [Commented] (TINKERPOP-1989) Preserve order that plugins are applied in Gremlin Console
[
https://issues.apache.org/jira/browse/TINKERPOP-1989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16518997#comment-16518997
]
ASF GitHub Bot commented on TINKERPOP-1989:
---
Github user jorgebay commented on the issue:
https://github.com/apache/tinkerpop/pull/880
lgtm, VOTE +1
> Preserve order that plugins are applied in Gremlin Console
> --
>
> Key: TINKERPOP-1989
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1989
> Project: TinkerPop
> Issue Type: Improvement
> Components: console
>Affects Versions: 3.2.9
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.4.0, 3.3.4, 3.2.10
>
>
> Plugins are now loaded in the order that {{ServiceLoader}} constructs them.
> Would be better if the plugins respected the order of the configuration file,
> that way the user could expect some control there in case one plugin depended
> on another for some reason. It's not a perfect system as users would be
> responsible for ordering, but it's a cheap, non-breaking way to at least
> provide some method for dealing with dependencies.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
