[jira] [Created] (TINKERPOP-1644) Improve script compilation syncronisation
Bryn Cooke created TINKERPOP-1644: - Summary: Improve script compilation syncronisation Key: TINKERPOP-1644 URL: https://issues.apache.org/jira/browse/TINKERPOP-1644 Project: TinkerPop Issue Type: Improvement Affects Versions: 3.2.4 Reporter: Bryn Cooke Currently there is no synchronisation around script compilation. This means that if a particularly heavy script is in use, many threads may end up compiling the same script. It would seem like a good idea to have some some sort of synchronisation to prevent ever getting to this stage. In addition, there will be cases where users will repeatedly submit broken scripts to the server. In this case it is useful to log the error the first time the script compilation is attempted and then cache the error for subsequent runs. Finally I have found some scripts take in excess of 30 seconds to compile. To aid performance debugging the script compilation times should be included in the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1644) Improve script compilation syncronisation
[ https://issues.apache.org/jira/browse/TINKERPOP-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] stephen mallette updated TINKERPOP-1644: Component/s: groovy > Improve script compilation syncronisation > - > > Key: TINKERPOP-1644 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1644 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > Currently there is no synchronisation around script compilation. This means > that if a particularly heavy script is in use, many threads may end up > compiling the same script. > It would seem like a good idea to have some some sort of synchronisation to > prevent ever getting to this stage. > In addition, there will be cases where users will repeatedly submit broken > scripts to the server. In this case it is useful to log the error the first > time the script compilation is attempted and then cache the error for > subsequent runs. > Finally I have found some scripts take in excess of 30 seconds to compile. To > aid performance debugging the script compilation times should be included in > the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1645) Bump to Groovy 2.4.9
stephen mallette created TINKERPOP-1645: --- Summary: Bump to Groovy 2.4.9 Key: TINKERPOP-1645 URL: https://issues.apache.org/jira/browse/TINKERPOP-1645 Project: TinkerPop Issue Type: Improvement Components: groovy Affects Versions: 3.1.6 Reporter: stephen mallette Assignee: stephen mallette Groovy released 2.4.9 in the last week or so. It's a small release with basically all bug fixes. One fix that might be important to TinkerPop is this one: GROOVY-8067 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] tinkerpop pull request #567: TINKERPOP-1644 Improve script compilation syncr...
GitHub user BrynCooke opened a pull request: https://github.com/apache/tinkerpop/pull/567 TINKERPOP-1644 Improve script compilation syncronisation Script compilation is synchronised. Script compilation times are placed in to logs. Failed scripts will not be recompiled. Scripts that take over 5 seconds to compile are logged as a warning. You can merge this pull request into a Git repository by running: $ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1644 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/567.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 #567 commit ca229694dc036210ad9e7ae2fc32134720b48d1b Author: BrynCooke Date: 2017-03-02T19:07:28Z TINKERPOP-1644 Improve script compilation syncronisation Script compilation is synchronised. Script compilation times are placed in to logs. Failed scripts will not be recompiled. Scripts that take over 5 seconds to compile are logged as a warning. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1644) Improve script compilation syncronisation
[ https://issues.apache.org/jira/browse/TINKERPOP-1644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897344#comment-15897344 ] ASF GitHub Bot commented on TINKERPOP-1644: --- GitHub user BrynCooke opened a pull request: https://github.com/apache/tinkerpop/pull/567 TINKERPOP-1644 Improve script compilation syncronisation Script compilation is synchronised. Script compilation times are placed in to logs. Failed scripts will not be recompiled. Scripts that take over 5 seconds to compile are logged as a warning. You can merge this pull request into a Git repository by running: $ git pull https://github.com/BrynCooke/incubator-tinkerpop TINKERPOP-1644 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/567.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 #567 commit ca229694dc036210ad9e7ae2fc32134720b48d1b Author: BrynCooke Date: 2017-03-02T19:07:28Z TINKERPOP-1644 Improve script compilation syncronisation Script compilation is synchronised. Script compilation times are placed in to logs. Failed scripts will not be recompiled. Scripts that take over 5 seconds to compile are logged as a warning. > Improve script compilation syncronisation > - > > Key: TINKERPOP-1644 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1644 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.2.4 >Reporter: Bryn Cooke > > Currently there is no synchronisation around script compilation. This means > that if a particularly heavy script is in use, many threads may end up > compiling the same script. > It would seem like a good idea to have some some sort of synchronisation to > prevent ever getting to this stage. > In addition, there will be cases where users will repeatedly submit broken > scripts to the server. In this case it is useful to log the error the first > time the script compilation is attempted and then cache the error for > subsequent runs. > Finally I have found some scripts take in excess of 30 seconds to compile. To > aid performance debugging the script compilation times should be included in > the logs. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] tinkerpop pull request #568: TINKERPOP-1645 Bump to groovy 2.4.9
GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/568 TINKERPOP-1645 Bump to groovy 2.4.9 https://issues.apache.org/jira/browse/TINKERPOP-1645 Just a version bump, but as it is a version bump an explicit vote would be good. I've only ran tests for 'tp31' at this point, but will run tests on the other branches prior to merge. There really shouldn't be any problems as this release of groovy was pretty small. VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1645 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/568.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 #568 commit cde8b316e2cfdc7d8a7d1d3456d68d0f3a5d9828 Author: Stephen Mallette Date: 2017-03-06T13:54:18Z TINKERPOP-1645 Bump to groovy 2.4.9 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1645) Bump to Groovy 2.4.9
[ https://issues.apache.org/jira/browse/TINKERPOP-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897346#comment-15897346 ] ASF GitHub Bot commented on TINKERPOP-1645: --- GitHub user spmallette opened a pull request: https://github.com/apache/tinkerpop/pull/568 TINKERPOP-1645 Bump to groovy 2.4.9 https://issues.apache.org/jira/browse/TINKERPOP-1645 Just a version bump, but as it is a version bump an explicit vote would be good. I've only ran tests for 'tp31' at this point, but will run tests on the other branches prior to merge. There really shouldn't be any problems as this release of groovy was pretty small. VOTE +1 You can merge this pull request into a Git repository by running: $ git pull https://github.com/apache/tinkerpop TINKERPOP-1645 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/568.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 #568 commit cde8b316e2cfdc7d8a7d1d3456d68d0f3a5d9828 Author: Stephen Mallette Date: 2017-03-06T13:54:18Z TINKERPOP-1645 Bump to groovy 2.4.9 > Bump to Groovy 2.4.9 > > > Key: TINKERPOP-1645 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1645 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.1.6 >Reporter: stephen mallette >Assignee: stephen mallette > > Groovy released 2.4.9 in the last week or so. It's a small release with > basically all bug fixes. One fix that might be important to TinkerPop is this > one: GROOVY-8067 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] tinkerpop issue #568: TINKERPOP-1645 Bump to groovy 2.4.9
Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/568 VOTE +1. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TINKERPOP-1645) Bump to Groovy 2.4.9
[ https://issues.apache.org/jira/browse/TINKERPOP-1645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897348#comment-15897348 ] ASF GitHub Bot commented on TINKERPOP-1645: --- Github user okram commented on the issue: https://github.com/apache/tinkerpop/pull/568 VOTE +1. > Bump to Groovy 2.4.9 > > > Key: TINKERPOP-1645 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1645 > Project: TinkerPop > Issue Type: Improvement > Components: groovy >Affects Versions: 3.1.6 >Reporter: stephen mallette >Assignee: stephen mallette > > Groovy released 2.4.9 in the last week or so. It's a small release with > basically all bug fixes. One fix that might be important to TinkerPop is this > one: GROOVY-8067 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (TINKERPOP-1646) Support custom implementor specific graph management
David Pitera created TINKERPOP-1646: --- Summary: Support custom implementor specific graph management Key: TINKERPOP-1646 URL: https://issues.apache.org/jira/browse/TINKERPOP-1646 Project: TinkerPop Issue Type: New Feature Reporter: David Pitera Priority: Minor Currently, Tinkerpop uses the [GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java) to handle graph management and store references to graph objects. I propose that we change the graphManager in three ways: 1. The graphManager should be an interface, and the existing functionality should be moved into a `BasicGraphManager`. This allows the implementor to design their own graph manager so suit their graph management needs. Furthermore, this will need to allow the implementor to supply a graphManager class in the YAML, so the [Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java) must support a graphmanager, which of course can default to the `BasicGraphManager`. 2. We define additional methods on the interface to improve how the graphManager is used in existing Tinkerpop code. For example, [here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156) we mutate an object directly outside the scope of a getter or setter on said object. 3. We define additional methods on the interface to allow for custom graph opening implementation: ``` /** * Implementation that allows for custom graph-opening implementations. */ public Graph openGraph(String graphName, Supplier supplier); ``` -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1646) Support custom implementor specific graph management
[ https://issues.apache.org/jira/browse/TINKERPOP-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Plurad updated TINKERPOP-1646: Component/s: server > Support custom implementor specific graph management > > > Key: TINKERPOP-1646 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1646 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.4 >Reporter: David Pitera >Priority: Minor > > Currently, Tinkerpop uses the > [GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java) > to handle graph management and store references to graph objects. > I propose that we change the graphManager in three ways: > 1. The graphManager should be an interface, and the existing functionality > should be moved into a `BasicGraphManager`. This allows the implementor to > design their own graph manager so suit their graph management needs. > Furthermore, this will need to allow the implementor to supply a graphManager > class in the YAML, so the > [Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java) > must support a graphmanager, which of course can default to the > `BasicGraphManager`. > 2. We define additional methods on the interface to improve how the > graphManager is used in existing Tinkerpop code. For example, > [here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156) > we mutate an object directly outside the scope of a getter or setter on said > object. > 3. We define additional methods on the interface to allow for custom graph > opening implementation: > ``` > /** > * Implementation that allows for custom graph-opening implementations. > */ > public Graph openGraph(String graphName, Supplier supplier); > ``` -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1646) Support custom implementor specific graph management
[ https://issues.apache.org/jira/browse/TINKERPOP-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Plurad updated TINKERPOP-1646: Priority: Major (was: Minor) > Support custom implementor specific graph management > > > Key: TINKERPOP-1646 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1646 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.4 >Reporter: David Pitera > > Currently, Tinkerpop uses the > [GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java) > to handle graph management and store references to graph objects. > I propose that we change the graphManager in three ways: > 1. The graphManager should be an interface, and the existing functionality > should be moved into a `BasicGraphManager`. This allows the implementor to > design their own graph manager so suit their graph management needs. > Furthermore, this will need to allow the implementor to supply a graphManager > class in the YAML, so the > [Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java) > must support a graphmanager, which of course can default to the > `BasicGraphManager`. > 2. We define additional methods on the interface to improve how the > graphManager is used in existing Tinkerpop code. For example, > [here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156) > we mutate an object directly outside the scope of a getter or setter on said > object. > 3. We define additional methods on the interface to allow for custom graph > opening implementation: > ``` > /** > * Implementation that allows for custom graph-opening implementations. > */ > public Graph openGraph(String graphName, Supplier supplier); > ``` -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1646) Support custom implementor specific graph management
[ https://issues.apache.org/jira/browse/TINKERPOP-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Plurad updated TINKERPOP-1646: Issue Type: Improvement (was: New Feature) > Support custom implementor specific graph management > > > Key: TINKERPOP-1646 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1646 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.4 >Reporter: David Pitera >Priority: Minor > > Currently, Tinkerpop uses the > [GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java) > to handle graph management and store references to graph objects. > I propose that we change the graphManager in three ways: > 1. The graphManager should be an interface, and the existing functionality > should be moved into a `BasicGraphManager`. This allows the implementor to > design their own graph manager so suit their graph management needs. > Furthermore, this will need to allow the implementor to supply a graphManager > class in the YAML, so the > [Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java) > must support a graphmanager, which of course can default to the > `BasicGraphManager`. > 2. We define additional methods on the interface to improve how the > graphManager is used in existing Tinkerpop code. For example, > [here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156) > we mutate an object directly outside the scope of a getter or setter on said > object. > 3. We define additional methods on the interface to allow for custom graph > opening implementation: > ``` > /** > * Implementation that allows for custom graph-opening implementations. > */ > public Graph openGraph(String graphName, Supplier supplier); > ``` -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (TINKERPOP-1646) Support custom implementor specific graph management
[ https://issues.apache.org/jira/browse/TINKERPOP-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Plurad updated TINKERPOP-1646: Affects Version/s: 3.2.4 > Support custom implementor specific graph management > > > Key: TINKERPOP-1646 > URL: https://issues.apache.org/jira/browse/TINKERPOP-1646 > Project: TinkerPop > Issue Type: Improvement > Components: server >Affects Versions: 3.2.4 >Reporter: David Pitera >Priority: Minor > > Currently, Tinkerpop uses the > [GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java) > to handle graph management and store references to graph objects. > I propose that we change the graphManager in three ways: > 1. The graphManager should be an interface, and the existing functionality > should be moved into a `BasicGraphManager`. This allows the implementor to > design their own graph manager so suit their graph management needs. > Furthermore, this will need to allow the implementor to supply a graphManager > class in the YAML, so the > [Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java) > must support a graphmanager, which of course can default to the > `BasicGraphManager`. > 2. We define additional methods on the interface to improve how the > graphManager is used in existing Tinkerpop code. For example, > [here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156) > we mutate an object directly outside the scope of a getter or setter on said > object. > 3. We define additional methods on the interface to allow for custom graph > opening implementation: > ``` > /** > * Implementation that allows for custom graph-opening implementations. > */ > public Graph openGraph(String graphName, Supplier supplier); > ``` -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Closed] (TINKERPOP-1646) Support custom implementor specific graph management
[
https://issues.apache.org/jira/browse/TINKERPOP-1646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stephen mallette closed TINKERPOP-1646.
---
Resolution: Duplicate
Assignee: stephen mallette
Thanks for submitting the issue and describing some steps to take Note that we
already have TINKERPOP-1438 that calls for {{GraphManager}} to become an
interface. Since we already have a long standing issue, I'm going to close this
one as a duplicate. I suggest you migrate your ideas over to that issue and
then discussion on this topic can continue over there.
> Support custom implementor specific graph management
>
>
> Key: TINKERPOP-1646
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1646
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.2.4
>Reporter: David Pitera
>Assignee: stephen mallette
>
> Currently, Tinkerpop uses the
> [GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java)
> to handle graph management and store references to graph objects.
> I propose that we change the graphManager in three ways:
> 1. The graphManager should be an interface, and the existing functionality
> should be moved into a `BasicGraphManager`. This allows the implementor to
> design their own graph manager so suit their graph management needs.
> Furthermore, this will need to allow the implementor to supply a graphManager
> class in the YAML, so the
> [Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java)
> must support a graphmanager, which of course can default to the
> `BasicGraphManager`.
> 2. We define additional methods on the interface to improve how the
> graphManager is used in existing Tinkerpop code. For example,
> [here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156)
> we mutate an object directly outside the scope of a getter or setter on said
> object.
> 3. We define additional methods on the interface to allow for custom graph
> opening implementation:
> ```
> /**
> * Implementation that allows for custom graph-opening implementations.
> */
> public Graph openGraph(String graphName, Supplier supplier);
> ```
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-786) Patterns for DSL Development
[ https://issues.apache.org/jira/browse/TINKERPOP-786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15897836#comment-15897836 ] stephen mallette commented on TINKERPOP-786: It occurs to me that I'm not sure how DSLs will work with the remoting API/GLVs. not sure if anyone has any thoughts on that. > Patterns for DSL Development > > > Key: TINKERPOP-786 > URL: https://issues.apache.org/jira/browse/TINKERPOP-786 > Project: TinkerPop > Issue Type: Improvement > Components: documentation >Affects Versions: 3.0.2-incubating >Reporter: stephen mallette >Assignee: stephen mallette > Fix For: 3.2.5 > > > Develop and document the patterns for custom DSLs. The method previously > described and under consideration at 3.0.0 seems a bit cumbersome to deal > with. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[GitHub] tinkerpop pull request #569: Tinkerpop 1438: GraphManager becomes a customiz...
GitHub user dpitera opened a pull request: https://github.com/apache/tinkerpop/pull/569 Tinkerpop 1438: GraphManager becomes a customizable interface You can merge this pull request into a Git repository by running: $ git pull https://github.com/dpitera/tinkerpop TINKERPOP-1438 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/tinkerpop/pull/569.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 #569 commit 445bce2e255499014921a3239f711951864919c5 Author: Stephen Mallette Date: 2016-12-20T21:00:36Z Ignore a tree test that's killing travis. Will be fixed as part of TINKERPOP-1509 CTR commit e152a5050ec3871a3217677c9ef539576d74b5f7 Author: Stephen Mallette Date: 2016-12-21T17:19:53Z Merge branch 'tp32' Conflicts: gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/io/gryo/GryoMapper.java commit 1998536f83d2c45cc44760ee6328cfcaed1a1c32 Author: Stephen Mallette Date: 2016-12-21T17:21:13Z Merge branch 'tp32' commit b0102688e37565a503e99b99d62c90527c22a730 Author: Stephen Mallette Date: 2016-12-22T18:00:20Z Merge branch 'tp32' commit d6501d3284fed1ab2bea66dc302a4a183ac67d34 Author: Stephen Mallette Date: 2016-12-23T12:37:11Z Merge branch 'tp32' commit 55e1678ce2fea9960adc9205e778cd1344fadcf8 Author: Stephen Mallette Date: 2016-12-23T12:46:51Z Added some missing imports to fix compile problems CTR commit 6c09b722c920965b10f912af8eb9d27d08e1cc10 Author: Stephen Mallette Date: 2016-12-27T15:37:19Z Merge branch 'tp32' commit a086fbe96201b82cdc70aa395e208061cd0bf85c Author: Stephen Mallette Date: 2016-12-28T13:37:03Z Merge branch 'tp32' commit 24ff9e879b7af17b0e20daf976005d806650f903 Author: Stephen Mallette Date: 2016-12-28T14:02:59Z Merge branch 'tp32' commit 59d0a6957b9b868d8c6ba0931108352732ee8275 Author: Stephen Mallette Date: 2016-12-29T10:39:48Z Merge branch 'tp32' commit a4bff0c34bb38f772035e608a878654763d7e097 Author: Stephen Mallette Date: 2016-12-29T11:29:28Z Merge branch 'tp32' commit 77bbb427cfd961ae2d5fa990f863efe10d5ce080 Author: Stephen Mallette Date: 2016-12-29T11:55:14Z Merge branch 'tp32' commit 3fc700fdc19a6cb44d57aecf457a00b8eba0346a Author: Marko A. Rodriguez Date: 2017-01-03T14:43:41Z merged Spark 2.0.0 work. Massive undertaking that provided us performance improvements. Thanks @dalaro and @yucx. commit df67d7a413e3525db7c69167c729c0522bbb8445 Author: Stephen Mallette Date: 2016-12-14T16:50:38Z TINKERPOP-1130 Structured the IO compatibility tests commit fc7b4457d8e740dc17bedafdd569db52e016b619 Author: Stephen Mallette Date: 2016-12-14T22:41:30Z TINKERPOP-1130 Implemented many additional IO tests. Cleaned up inconsistencies in how static files are stored. Improved asserts. commit 8a2241c2cb290a9ac6b4976967ef16bfff485fe6 Author: Stephen Mallette Date: 2016-12-15T16:55:16Z TINKERPOP-1130 Completed tests for typed IO Still need some asserts and found lots of inconsistencies that were handled in the Model class with Compatibility assignments. commit a10910f7dcd97cac274534e24cf0c4973376795f Author: Stephen Mallette Date: 2016-12-15T18:58:20Z TINKERPOP-1130 Made the test data for metrics static. This helps prevent the data from regenerating on every build. commit 4549ed025fe7d1dac9ed486a085a3aaf936cbd07 Author: Stephen Mallette Date: 2016-12-15T19:40:00Z TINKERPOP-1130 Improved asserts on Graph elements. commit fb0bb0182f9fd9becf64b06c90a08988e6fc0f2e Author: Stephen Mallette Date: 2016-12-16T11:56:55Z TINKERPOP-1130 Changed scope of gremlin-test to "test" commit ab206a728e441cfe643a30973172115e179a97d4 Author: Stephen Mallette Date: 2016-12-19T14:16:11Z TINKERPOP-1130 Add gremlin-test back as compile scope. It can't be test scope since non-test code uses commons-io which comes from gremlin-test. Shouldn't be any harm in including gremlin-test this way as this is a utility module that isn't deployed or anything. commit 50d179d31ad03adc3d16b37f6261777898b82c22 Author: Stephen Mallette Date: 2016-12-21T20:35:23Z TINKERPOP-1130 Get the basics of Gryo 3.0 in place. commit 7503d33a6fb4df9e8e1471162a87456195ef6fe9 Author: Stephen Mallette Date: 2016-12-21T20:52:30Z TINKERPOP-1130 Enabled testing of int/double for GraphSON Thanks to fixes in tp32/master it's now possible to test these primitive data types. commit 12b472d6c1153f20ccb8689fd8ff88feabfb1dee Author: Stephen Mallette Date: 2016-12-22T18:39:10Z TINKERPOP-1130 Enabled GraphSON serialization tests for enums Fixes on tp32 related to enum serialization allowed these tests to start working. commit cc5904d5d88049df541280b794bf7d8e694539b8 Author: Stephen Mallette Date: 201
Re: [DISCUSS] Add ChronoGraph to Provider Index
... well, since nobody had any objections, I guess that means it's accepted, right? I would be very happy to be listed as an official TinkerPop implementation. On 2017-03-01 00:14 ( 0100), Stephen Mallette wrote: > ChronoGraph was announced on Gremlin Users a day or so ago:> > > https://groups.google.com/forum/#!topic/gremlin-users/sWFUMYtY1t0> > > That project now has an official release on Maven Central> > > http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com.github.martinhaeusler%22> > > which I think allows it to meet the basic criteria of our index policy.> > Unless there are objections in the next 72 hours, I'll assume lazy> > consensus and get it added.> >
Re: [DISCUSS] Add ChronoGraph to Provider Index
Yes - I will get it done - I just haven't had a chance yet. I'll post back here when it's done. On Mon, Mar 6, 2017 at 3:22 PM, Martin Häusler wrote: > ... well, since nobody had any objections, I guess that means it's > accepted, right? I would be very happy to be listed as an official > TinkerPop implementation. > > > > On 2017-03-01 00:14 ( 0100), Stephen Mallette wrote: > > ChronoGraph was announced on Gremlin Users a day or so ago:> > > > > https://groups.google.com/forum/#!topic/gremlin-users/sWFUMYtY1t0> > > > > That project now has an official release on Maven Central> > > > > > http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22com. > github.martinhaeusler%22> > > > > > which I think allows it to meet the basic criteria of our index policy.> > > Unless there are objections in the next 72 hours, I'll assume lazy> > > consensus and get it added.> > > >
[jira] [Commented] (TINKERPOP-1438) Consider GraphManager as an interface
[
https://issues.apache.org/jira/browse/TINKERPOP-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15898062#comment-15898062
]
David Pitera commented on TINKERPOP-1438:
-
Copying over from the issue I created:
Currently, Tinkerpop uses the
[GraphManager](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/GraphManager.java)
to handle graph management and store references to graph objects.
I propose that we change the graphManager in three ways:
1. The graphManager should be an interface, and the existing functionality
should be moved into a `BasicGraphManager`. This allows the implementor to
design their own graph manager so suit their graph management needs.
Furthermore, this will need to allow the implementor to supply a graphManager
class in the YAML, so the
[Settings](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/Settings.java)
must support a graphmanager, which of course can default to the
`BasicGraphManager`.
2. We define additional methods on the interface to improve how the
graphManager is used in existing Tinkerpop code. For example,
[here](https://github.com/apache/tinkerpop/blob/master/gremlin-server/src/main/java/org/apache/tinkerpop/gremlin/server/util/ServerGremlinExecutor.java#L156)
we mutate an object directly outside the scope of a getter or setter on said
object.
3. We define additional methods on the interface to allow for custom graph
opening implementation:
// Implementation that allows for custom graph-opening implementations.
public Graph openGraph(String graphName, Supplier supplier);
> Consider GraphManager as an interface
> -
>
> Key: TINKERPOP-1438
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1438
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Priority: Minor
> Labels: breaking
>
> If {{GraphManager}} were an interface it would make embedding Gremlin Server
> easier as {{Graph}} instances could be more easily supplied by the host
> application. In doing this, It also might be good to force a
> {{TraversalSource}} to be referred to by both the {{Graph}} name and
> {{TraversalSource}} name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (TINKERPOP-1438) Consider GraphManager as an interface
[
https://issues.apache.org/jira/browse/TINKERPOP-1438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15898066#comment-15898066
]
David Pitera commented on TINKERPOP-1438:
-
Hey as it turns out I've opened a PR that already addresses all of these
concerns.
The PR is here: https://github.com/apache/tinkerpop/pull/569/files
> Consider GraphManager as an interface
> -
>
> Key: TINKERPOP-1438
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1438
> Project: TinkerPop
> Issue Type: Improvement
> Components: server
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Priority: Minor
> Labels: breaking
>
> If {{GraphManager}} were an interface it would make embedding Gremlin Server
> easier as {{Graph}} instances could be more easily supplied by the host
> application. In doing this, It also might be good to force a
> {{TraversalSource}} to be referred to by both the {{Graph}} name and
> {{TraversalSource}} name.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (TINKERPOP-1647) Create a Stateful interface for steps that have internal state.
Marko A. Rodriguez created TINKERPOP-1647:
-
Summary: 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: Bug
Components: process
Affects Versions: 3.2.4
Reporter: Marko A. Rodriguez
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
(v6.3.15#6346)
