Re: [VOTE] TinkerPop 3.2.6 Release

[pieter gmail]

Ran Sqlg's own test suite and TinkerPop's structured and process test 
suites on Sqlg.

All passes.

VOTE +1

Cheers
Pieter


On 22/08/2017 20:29, Robert Dale wrote:

VOTE +1

Robert Dale

On Tue, Aug 22, 2017 at 10:33 AM, Daniel Kuppitz  wrote:


*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.2.6-bin.zip)... OK
* validating signatures and checksums ...
   * PGP signature ... OK
   * MD5 checksum ... OK
   * SHA1 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
   * LICENSE ... OK
   * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK
* testing script evaluation ... OK

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-server-3.2.6-bin.zip)... OK
* validating signatures and checksums ...
   * PGP signature ... OK
   * MD5 checksum ... OK
   * SHA1 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
   * LICENSE ... OK
   * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK

Validating source distribution

* downloading Apache TinkerPop 3.2.6 (apache-tinkerpop-3.2.6-src.zip)...
OK
* validating signatures and checksums ...
   * PGP signature ... OK
   * MD5 checksum ... OK
   * SHA1 checksum ... OK
* unzipping Apache TinkerPop 3.2.6 ... OK
* building project ... OK



VOTE: +1

Cheers,
Daniel


On Tue, Aug 22, 2017 at 4:54 AM, Stephen Mallette 
wrote:


Hello,

We are happy to announce that TinkerPop 3.2.6 is ready for release.

The release artifacts can be found at this location:
 https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.6/

The source distribution is provided by:
 apache-tinkerpop-3.2.6-src.zip

Two binary distributions are provided for user convenience:
 apache-tinkerpop-gremlin-console-3.2.6-bin.zip
 apache-tinkerpop-gremlin-server-3.2.6-bin.zip

The GPG key used to sign the release artifacts is available at:
 https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
 http://tinkerpop.apache.org/docs/3.2.6/ (user docs)
 http://tinkerpop.apache.org/docs/3.2.6/upgrade/ (upgrade docs)
 http://tinkerpop.apache.org/javadocs/3.2.6/core/ (core javadoc)
 http://tinkerpop.apache.org/javadocs/3.2.6/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
43ed34fb10002308117b6cfabd4870d958cc2d99

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.2.6/
CHANGELOG.asciidoc#tinkerpop-326-release-date-august-21-2017

The [VOTE] will be open for the next 72 hours --- closing Friday (August
25, 2017) at 8AM EST.

My vote is +1.

Thank you very much,
Stephen

Re: Request to add Gremlin OGM to TinkerPop's Index Listing

[Karthick Sankarachary]

Thanks Stephen, much appreciated! I'm looking forward to the 3.3.0 release.

Best Regards,
Karthick Sankarachary

On 2017-08-22 09:41, Stephen Mallette  wrote: 
> I've added this to the source:
> 
> https://github.com/apache/tinkerpop/blob/master/docs/site/home/index.html#L263
> 
> It will publish when we release 3.3.0 then we can tweet and promote the
> addition.
> 
> On Sat, Aug 19, 2017 at 2:39 PM, Karthick Sankarachary 
> wrote:
> 
> > Hello, TinkerPop Community,
> >
> > I'd like to request that the "gremlin-objects" project (
> > https://github.com/karthicks/gremlin-ogm), a
> > TinkerPop-enabled middleware tool, be added to the TinkerPop homepage
> > index.html.
> >
> > I believe that it would make a nice addition under the "Query Languages"
> > section on the
> > homepage, as a line item such as this:
> > https://github.com/karthicks/gremlin-ogm;>gremlin-objects
> > (java/dsl) - An Object Graph Mapping Library For Gremlin.
> >
> > The "gremlin-objects" project has already been vetted to some degree in
> > the following thread:
> > https://lists.apache.org/thread.html/6af7b277ce435dcd71f8c921c276d9
> > 6032f01a1fbe9b4cfdeaadc81d@%3Cdev.tinkerpop.apache.org%3E
> >
> > For what it's worth, it is production-ready code in that it was used to
> > implement a TinkerPop
> > solution powered by DataStax Enterprise Graph, for the startup I work for,
> > viz., Elementum
> > (http://elementum.com), a Product Graph company.
> >
> > My hope is that this project will add some value to the community and that
> > likewise, the community
> > will contribute features back to that project, which I could potentially
> > leverage at Elementum.
> >
> > Best Regards,
> > Karthick Sankarachary
> > karth...@apache.org
> >
> 

Re: [VOTE] TinkerPop 3.2.6 Release

[Robert Dale]

VOTE +1

Robert Dale

On Tue, Aug 22, 2017 at 10:33 AM, Daniel Kuppitz  wrote:

> *Validating binary distributions*
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-console-3.2.6-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
> * testing script evaluation ... OK
>
> * downloading Apache TinkerPop Gremlin
> (apache-tinkerpop-gremlin-server-3.2.6-bin.zip)... OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
>
> Validating source distribution
>
> * downloading Apache TinkerPop 3.2.6 (apache-tinkerpop-3.2.6-src.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop 3.2.6 ... OK
> * building project ... OK
>
>
>
> VOTE: +1
>
> Cheers,
> Daniel
>
>
> On Tue, Aug 22, 2017 at 4:54 AM, Stephen Mallette 
> wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.6 is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.6/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.6-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.2.6-bin.zip
> > apache-tinkerpop-gremlin-server-3.2.6-bin.zip
> >
> > The GPG key used to sign the release artifacts is available at:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > The online docs can be found here:
> > http://tinkerpop.apache.org/docs/3.2.6/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.6/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.6/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.6/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> >
> > https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> > 43ed34fb10002308117b6cfabd4870d958cc2d99
> >
> > The release notes are available here:
> >
> > https://github.com/apache/tinkerpop/blob/3.2.6/
> > CHANGELOG.asciidoc#tinkerpop-326-release-date-august-21-2017
> >
> > The [VOTE] will be open for the next 72 hours --- closing Friday (August
> > 25, 2017) at 8AM EST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> > Stephen
> >
>

Re: [VOTE] TinkerPop 3.3.0 Release

[Daniel Kuppitz]

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.3.0-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK
* testing script evaluation ... OK

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-server-3.3.0-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK

Validating source distribution

* downloading Apache TinkerPop 3.3.0 (apache-tinkerpop-3.3.0-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop 3.3.0 ... OK
* building project ... OK


VOTE: +1

Cheers,
Daniel


On Tue, Aug 22, 2017 at 8:57 AM, Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.3.0 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.0/
>
> The source distribution is provided by:
> apache-tinkerpop-3.3.0-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.3.0-bin.zip
> apache-tinkerpop-gremlin-server-3.3.0-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.3.0/ (user docs)
> http://tinkerpop.apache.org/docs/3.3.0/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.3.0/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.3.0/full/ (full javadoc)
>
> The tag in Apache Git can be found here:
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> e8aa977ab33e0ceec6ac9d06a3262d52b4e16511
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/3.3.0/
> CHANGELOG.asciidoc#tinkerpop-330-release-date-august-21-2017
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (August
> 21, 2017) at 12pm EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>

Re: Request to add Gremlin OGM to TinkerPop's Index Listing

[Stephen Mallette]

I've added this to the source:

https://github.com/apache/tinkerpop/blob/master/docs/site/home/index.html#L263

It will publish when we release 3.3.0 then we can tweet and promote the
addition.

On Sat, Aug 19, 2017 at 2:39 PM, Karthick Sankarachary 
wrote:

> Hello, TinkerPop Community,
>
> I'd like to request that the "gremlin-objects" project (
> https://github.com/karthicks/gremlin-ogm), a
> TinkerPop-enabled middleware tool, be added to the TinkerPop homepage
> index.html.
>
> I believe that it would make a nice addition under the "Query Languages"
> section on the
> homepage, as a line item such as this:
> https://github.com/karthicks/gremlin-ogm;>gremlin-objects
> (java/dsl) - An Object Graph Mapping Library For Gremlin.
>
> The "gremlin-objects" project has already been vetted to some degree in
> the following thread:
> https://lists.apache.org/thread.html/6af7b277ce435dcd71f8c921c276d9
> 6032f01a1fbe9b4cfdeaadc81d@%3Cdev.tinkerpop.apache.org%3E
>
> For what it's worth, it is production-ready code in that it was used to
> implement a TinkerPop
> solution powered by DataStax Enterprise Graph, for the startup I work for,
> viz., Elementum
> (http://elementum.com), a Product Graph company.
>
> My hope is that this project will add some value to the community and that
> likewise, the community
> will contribute features back to that project, which I could potentially
> leverage at Elementum.
>
> Best Regards,
> Karthick Sankarachary
> karth...@apache.org
>

Re: [VOTE] TinkerPop 3.1.8 Release

[Stephen Mallette]

validate-distribution.sh was good to go for me so:

VOTE +1

for the last of the 3.1.x and the tp31 branch - bye!

On Mon, Aug 21, 2017 at 5:00 PM, Daniel Kuppitz  wrote:

> *$ bin/validate-distribution.sh 3.1.8*
>
> Validating binary distributions
>
> * downloading Apache TinkerPop Gremlin 
> (apache-tinkerpop-gremlin-console-3.1.8-bin.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
> * testing script evaluation ... OK
>
> * downloading Apache TinkerPop Gremlin 
> (apache-tinkerpop-gremlin-server-3.1.8-bin.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop Gremlin ... OK
> * validating Apache TinkerPop Gremlin's docs ... OK
> * validating Apache TinkerPop Gremlin's binaries ... OK
> * validating Apache TinkerPop Gremlin's legal files ...
>   * LICENSE ... OK
>   * NOTICE ... OK
> * validating Apache TinkerPop Gremlin's plugin directory ... OK
> * validating Apache TinkerPop Gremlin's lib directory ... OK
>
> Validating source distribution
>
> * downloading Apache TinkerPop 3.1.8 (apache-tinkerpop-3.1.8-src.zip)...
> OK
> * validating signatures and checksums ...
>   * PGP signature ... OK
>   * MD5 checksum ... OK
>   * SHA1 checksum ... OK
> * unzipping Apache TinkerPop 3.1.8 ... OK
> * building project ... OK
>
>
> VOTE: +1
>
> ...and R.I.P. 3.1 line.
>
>
> ​
>
> Cheers,
> Daniel
>
>
> On Mon, Aug 21, 2017 at 1:33 PM, Ted Wilmes  wrote:
>
>> Hello,
>>
>> We are happy to announce that TinkerPop 3.1.8 is ready for release.
>>
>> The release artifacts can be found at this location:
>> https://dist.apache.org/repos/dist/dev/tinkerpop/3.1.8/
>>
>> The source distribution is provided by:
>> apache-tinkerpop-3.1.8-src.zip
>>
>> Two binary distributions are provided for user convenience:
>> apache-tinkerpop-gremlin-console-3.1.8-bin.zip
>> apache-tinkerpop-gremlin-server-3.1.8-bin.zip
>>
>> The GPG key used to sign the release artifacts is available at:
>> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>>
>> The online docs can be found here:
>> http://tinkerpop.apache.org/docs/3.1.8/ (user docs)
>> http://tinkerpop.apache.org/docs/3.1.8/upgrade/ (upgrade docs)
>> http://tinkerpop.apache.org/javadocs/3.1.8/core/ (core javadoc)
>> http://tinkerpop.apache.org/javadocs/3.1.8/full/ (full javadoc)
>>
>> The tag in Apache Git can be found here:
>>
>> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=co
>> mmit;h=77592c70ece5bff0de3cfe769459e1e467318798
>>
>> The release notes are available here:
>>
>> https://github.com/apache/tinkerpop/blob/3.1.8/CHANGELOG.
>> asciidoc#tinkerpop-318-release-date-august-21-2017
>>
>> The [VOTE] will be open for the next 72 hours --- closing Thursday (August
>> 24, 2017) at 4pm CST.
>>
>> My vote is +1.
>>
>> Thank you very much,
>> Ted Wilmes
>>
>
>

[VOTE] TinkerPop 3.3.0 Release

[Stephen Mallette]

Hello,

We are happy to announce that TinkerPop 3.3.0 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.0/

The source distribution is provided by:
apache-tinkerpop-3.3.0-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.3.0-bin.zip
apache-tinkerpop-gremlin-server-3.3.0-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.3.0/ (user docs)
http://tinkerpop.apache.org/docs/3.3.0/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.3.0/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.3.0/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=e8aa977ab33e0ceec6ac9d06a3262d52b4e16511

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.3.0/CHANGELOG.asciidoc#tinkerpop-330-release-date-august-21-2017

The [VOTE] will be open for the next 72 hours --- closing Friday (August
21, 2017) at 12pm EST.

My vote is +1.

Thank you very much,
Stephen

Re: [VOTE] TinkerPop 3.2.6 Release

[Daniel Kuppitz]

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.2.6-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK
* testing script evaluation ... OK

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-server-3.2.6-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop Gremlin ... OK
* validating Apache TinkerPop Gremlin's docs ... OK
* validating Apache TinkerPop Gremlin's binaries ... OK
* validating Apache TinkerPop Gremlin's legal files ...
  * LICENSE ... OK
  * NOTICE ... OK
* validating Apache TinkerPop Gremlin's plugin directory ... OK
* validating Apache TinkerPop Gremlin's lib directory ... OK

Validating source distribution

* downloading Apache TinkerPop 3.2.6 (apache-tinkerpop-3.2.6-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * MD5 checksum ... OK
  * SHA1 checksum ... OK
* unzipping Apache TinkerPop 3.2.6 ... OK
* building project ... OK



VOTE: +1

Cheers,
Daniel


On Tue, Aug 22, 2017 at 4:54 AM, Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.2.6 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.6/
>
> The source distribution is provided by:
> apache-tinkerpop-3.2.6-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.2.6-bin.zip
> apache-tinkerpop-gremlin-server-3.2.6-bin.zip
>
> The GPG key used to sign the release artifacts is available at:
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
>
> The online docs can be found here:
> http://tinkerpop.apache.org/docs/3.2.6/ (user docs)
> http://tinkerpop.apache.org/docs/3.2.6/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.2.6/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.2.6/full/ (full javadoc)
>
> The tag in Apache Git can be found here:
>
> https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=
> 43ed34fb10002308117b6cfabd4870d958cc2d99
>
> The release notes are available here:
>
> https://github.com/apache/tinkerpop/blob/3.2.6/
> CHANGELOG.asciidoc#tinkerpop-326-release-date-august-21-2017
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (August
> 25, 2017) at 8AM EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>

[jira] [Closed] (TINKERPOP-1404) Path/label optimization

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1404.
---
Resolution: Fixed

> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a 
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r, 
> step)}} is called there is no need to call {{Traverser.addLabels}} again in 
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} 
> the step's labels can be used directly in the traverser. There is no need to 
> make a copy of it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1404) Path/label optimization

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1404:
-

> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a 
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r, 
> step)}} is called there is no need to call {{Traverser.addLabels}} again in 
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} 
> the step's labels can be used directly in the traverser. There is no need to 
> make a copy of it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (TINKERPOP-1566) Kerberos authentication for gremlin-server

[stephen mallette (JIRA)]

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

stephen mallette closed TINKERPOP-1566.
---
Resolution: Fixed

> Kerberos authentication for gremlin-server
> --
>
> Key: TINKERPOP-1566
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1566
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Marc de Lignie
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.0
>
>
> Gremlin server would benefit from an explicit Kerberos authentication plugin, 
> because preparing and maintaining such a plugin is nontrivial. Also, many 
> other Apache project provide kerberized services.
> In gremlin-console the standard Krb5LoginModule can be configured. 
> Gremlin-server already includes the pluggable Sasl framework that can host 
> the proposed Kerberos authentication plugin. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1404) Path/label optimization

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1404:

Labels:   (was: performance)

> Path/label optimization
> ---
>
> Key: TINKERPOP-1404
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1404
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.1
>Reporter: pieter martin
>Assignee: pieter martin
> Fix For: 3.3.0
>
>
> Currently path queries do a lot of label collection copying. This has a 
> significant impact on performance.
> As the labels are known and set on the traverser when {{Traverser.split(r, 
> step)}} is called there is no need to call {{Traverser.addLabels}} again in 
> {{AbstractStep}}
> Also seeing as {{AbstractStep.getLabels()}} returns an {{UnmodifyableSet}} 
> the step's labels can be used directly in the traverser. There is no need to 
> make a copy of it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1566) Kerberos authentication for gremlin-server

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1566:

Labels:   (was: security)

> Kerberos authentication for gremlin-server
> --
>
> Key: TINKERPOP-1566
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1566
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Marc de Lignie
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.0
>
>
> Gremlin server would benefit from an explicit Kerberos authentication plugin, 
> because preparing and maintaining such a plugin is nontrivial. Also, many 
> other Apache project provide kerberized services.
> In gremlin-console the standard Krb5LoginModule can be configured. 
> Gremlin-server already includes the pluggable Sasl framework that can host 
> the proposed Kerberos authentication plugin. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Reopened] (TINKERPOP-1566) Kerberos authentication for gremlin-server

[stephen mallette (JIRA)]

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

stephen mallette reopened TINKERPOP-1566:
-

> Kerberos authentication for gremlin-server
> --
>
> Key: TINKERPOP-1566
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1566
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Reporter: Marc de Lignie
>Assignee: stephen mallette
>Priority: Minor
>  Labels: security
> Fix For: 3.3.0
>
>
> Gremlin server would benefit from an explicit Kerberos authentication plugin, 
> because preparing and maintaining such a plugin is nontrivial. Also, many 
> other Apache project provide kerberized services.
> In gremlin-console the standard Krb5LoginModule can be configured. 
> Gremlin-server already includes the pluggable Sasl framework that can host 
> the proposed Kerberos authentication plugin. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[VOTE] TinkerPop 3.2.6 Release

[Stephen Mallette]

Hello,

We are happy to announce that TinkerPop 3.2.6 is ready for release.

The release artifacts can be found at this location:
https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.6/

The source distribution is provided by:
apache-tinkerpop-3.2.6-src.zip

Two binary distributions are provided for user convenience:
apache-tinkerpop-gremlin-console-3.2.6-bin.zip
apache-tinkerpop-gremlin-server-3.2.6-bin.zip

The GPG key used to sign the release artifacts is available at:
https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS

The online docs can be found here:
http://tinkerpop.apache.org/docs/3.2.6/ (user docs)
http://tinkerpop.apache.org/docs/3.2.6/upgrade/ (upgrade docs)
http://tinkerpop.apache.org/javadocs/3.2.6/core/ (core javadoc)
http://tinkerpop.apache.org/javadocs/3.2.6/full/ (full javadoc)

The tag in Apache Git can be found here:

https://git-wip-us.apache.org/repos/asf?p=tinkerpop.git;a=tag;h=43ed34fb10002308117b6cfabd4870d958cc2d99

The release notes are available here:

https://github.com/apache/tinkerpop/blob/3.2.6/CHANGELOG.asciidoc#tinkerpop-326-release-date-august-21-2017

The [VOTE] will be open for the next 72 hours --- closing Friday (August
25, 2017) at 8AM EST.

My vote is +1.

Thank you very much,
Stephen

[jira] [Updated] (TINKERPOP-1515) One test suite to rule them all

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1515:

Fix Version/s: (was: 3.3.0)
   3.3.1

> One test suite to rule them all
> ---
>
> Key: TINKERPOP-1515
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1515
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: test-suite
>Affects Versions: 3.2.2
>Reporter: stephen mallette
>Assignee: stephen mallette
>  Labels: breaking
> Fix For: 3.3.1
>
>
> Make an attempt at an uber test module that would collapse all provider 
> related tests into a single module. I say "attempt" as I'm not completely 
> aware of what kinds of dependency conflicts I'll see try to do this.  
> Consider TINKERPOP-1410 in doing this.
> Obviously this change would be breaking if modules are combined and package 
> renaming occurs.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1535) Bump to support Giraph 1.2.0.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1535:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Bump to support Giraph 1.2.0.
> -
>
> Key: TINKERPOP-1535
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1535
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop
>Affects Versions: 3.2.3
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.3.1
>
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1128) Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1128:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Change the Gryo serialization for StarGraph (Vertex, Properties, then Edges)
> 
>
> Key: TINKERPOP-1128
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1128
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.1
>
>
> Right now we serialize first the vertex, then its edges, then its properties. 
> We should do vertex, properties, edges. Why? If we know that the vertex is to 
> be filtered (which is an analysis of its label/id/properties), then we can 
> skip over analyzing its edges. Right now, we may do all this work 
> deserializing edges only to realize that the {{GraphFilter}} says that the 
> vertex is filtered. Dah, pointless clock cycles -- especially when edge sets 
> can be massive.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1692) Bump to Neo4j 3.0.3

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1692:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Bump to Neo4j 3.0.3
> ---
>
> Key: TINKERPOP-1692
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1692
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: neo4j
>Affects Versions: 3.2.5
>Reporter: stephen mallette
> Fix For: 3.3.1
>
>
> There is a newer version of Neo4j available - 
> https://mvnrepository.com/artifact/org.neo4j/neo4j-tinkerpop-api-impl/0.4-3.0.3



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1326) Use KryoShim for serialization in VertexProgramHelper

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1326:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Use KryoShim for serialization in VertexProgramHelper
> -
>
> Key: TINKERPOP-1326
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1326
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, process, structure
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.1
>
>
> At the next major release, we should swap out the Java serialization work in 
> {{VertexProgramHelper}} and instead, use the {{KryoShim}} work developed by 
> [~dalaro]. This means we need a {{KryoShimService}} in {{gremlin-core}}. I 
> say we remove the {{HadoopPoolsKryoShimService}} and go with a 
> {{GryoPoolKryoShimService}} that then Hadoop-based OLAP engines can use (as 
> well as engines like TinkerGraph).
> This would a a "minor breaking" change as I suspect no provider is that deep 
> into the serialization API of TinkerPop and the change would be a simple 
> "change X to Y" sort of change for them.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-878) Refactor Gremlin Server integration tests to be Client parameterized

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-878:
---
Fix Version/s: (was: 3.3.0)
   3.3.1

> Refactor Gremlin Server integration tests to be Client parameterized
> 
>
> Key: TINKERPOP-878
> URL: https://issues.apache.org/jira/browse/TINKERPOP-878
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: stephen mallette
>Priority: Minor
> Fix For: 3.3.1
>
>
> Would be nice if Gremlin Server integration tests (at least the ones that 
> make sense anyway) were executed over both Websockets and NIO to generally 
> validate their capabilities.  We could likely create parameterized tests to 
> do this.  That would also pave the way for easily testing new transports if 
> they are ever added.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1344) ReferenceYYYXXX for better message passing

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1344:

Fix Version/s: (was: 3.3.0)
   3.3.1

> ReferenceYYYXXX for better message passing
> --
>
> Key: TINKERPOP-1344
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1344
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.3.1
>
>
> In https://issues.apache.org/jira/browse/TINKERPOP-1343, I was saying that it 
> would be nice to have the element id type be known so we can do 
> {{writeObject()}} as opposed to {{writeObjectAndClass()}}. I think we could 
> do some good with a hiearchy of classes like:
> {code}
> ReferenceIntVertex
> ReferenceLongVertex
> ReferenceVertex (Object -- what we have now)
> ReferenceUUIDVertex
> ...
> {code}
> ...likewise for Edge, VertexProperty...
> This will save us an extra 32-bits (4 byte int) on the serialization of 
> messages during OLAP message pass as that is all {{ReferenceXXX}} based.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1717) Update name and link of DynamoDB storage backend in landing page

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1717:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Update name and link of DynamoDB storage backend in landing page
> 
>
> Key: TINKERPOP-1717
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1717
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.2.3
>Reporter: Alexander Patrikalakis
>Priority: Minor
> Fix For: 3.3.1
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> Amazon have released DynamoDB storage backends compatible with JG 0.1.0 and 
> 0.1.1:
> https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.0.0
> https://mvnrepository.com/artifact/com.amazonaws/dynamodb-janusgraph-storage-backend/1.1.0
> Also, we have renamed the repository on GitHub to 
> dynamodb-janusgraph-storage-backend for git history continuity. So, can we 
> update the names and links on the landing page? Also minor, I would like to 
> update the capitalization of "storage backend" -> "Storage Backend"
> Before:
> [Titan (Amazon)](https://github.com/awslabs/dynamodb-titan-storage-backend/)  
> - The Amazon DynamoDB storage backend for Titan.
> After:
> [JanusGraph 
> (Amazon)](https://github.com/awslabs/dynamodb-janusgraph-storage-backend/)  - 
> The Amazon DynamoDB Storage Backend for JanusGraph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1346) Create custom ReferenceXXX GryoSerializers

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1346:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Create custom ReferenceXXX GryoSerializers
> --
>
> Key: TINKERPOP-1346
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1346
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io, structure
>Affects Versions: 3.2.0-incubating
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.1
>
>
> Right now, to send a {{ReferenceEdge}} message, we serialize the form as:
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassObject[Edge ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID] + 
> KryoClassInteger[ReferenceVertex] + KryoClassObject[Vertex ID]
> {code}
> Assuming {{Long}} Element ids, the math says:
> {code}
> 48 bytes = 4 bytes + (4 bytes + 8 bytes [long]) + 4 bytes + (4 bytes + 8 
> bytes [long]) + 4 bytes + (4 bytes + 8 bytes [long])
> {code}
> We could get this smaller by not relying on Kryo's {{FieldSerializer}}.
> {code}
> KryoClassInteger[ReferenceEdge] + KryoClassInteger[VertexIDClass] + 
> KryoClassObject[Edge ID] + KryoObject[Vertex ID] + KryoObject[Vertex ID]
> {code}
> The math says:
> {code}
> 36 bytes = 4 bytes + 4 bytes + (4 bytes + 8 bytes [long]) + 8 bytes [long] + 
> 8 bytes [long]
> {code}
> Similar techniques would apply to {{ReferenceVertexProperty}} and 
> {{ReferenceProperty}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1403) Provide support for GraphFilter.vertexProperties()

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1403:

Fix Version/s: (was: 3.3.0)
   3.3.1

> Provide support for GraphFilter.vertexProperties()
> --
>
> Key: TINKERPOP-1403
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1403
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process, structure
>Affects Versions: 3.2.1
>Reporter: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.3.1
>
>
> [~rspitzer] stated that he is working with a graph that has millions of 
> vertex properties on a vertex. If those properties are not needed for the 
> traversal, then they should be filtered out.
> Much like {{GraphFilter.edges()}}, we should add 
> {{GraphFilter.vertexProperties(Traversal)}}. That is, 
> from the {{Vertex}} in question, traverse to those properties needed in the 
> computation, where {{properties().limit(0)}} would be the push down predicate 
> for "no properties." Another example, {{properties("income")}} would only 
> provide income properties. Another example, 
> {{properties("income").has("acl","public")}} would provide only those income 
> properties that are public (according to access control).
> --- SIDENOTE. In the docs we have {{bothE().limit(0)}} as the predicate for 
> no edges. However, {{limit(0)}} by itself is sufficient. Likewise for 
> {{GraphFilter.vertexProperties()}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-942) Use EventStrategy to solve OLAP bulk mutation of OLTP.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-942:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Use EventStrategy to solve OLAP bulk mutation of OLTP.
> --
>
> Key: TINKERPOP-942
> URL: https://issues.apache.org/jira/browse/TINKERPOP-942
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>
> We need to be able to do this in TinkerPop3.
> https://github.com/thinkaurelius/faunus/wiki/Distributed-Graph-Computing-with-Gremlin
> This can be solved with {{EventStrategy}}. 
> Lets think of the hardest problem first -- distributed graph database (e.g. 
> Titan) being mutated by a distributed graph processor (e.g. Giraph). Each 
> Giraph node will map to a Titan node. Then the Giraph node will create a 
> connection back to the respective Titan node via the {{writeGraph}} model by 
> [~dkuppitz] in {{BulkLoaderVertexProgram}}. Every time a {{addV()}}, 
> {{addE()}}, {{property()}} is called, an event is fired and THAT event is 
> call back to the Titan to create the vertex/edge/property. Likewise for 
> {{drop()}}, etc. In other words, all {{Mutating}} steps can have a call back 
> in OLAP to mutate the OLTP system.
> What about the easy case of {{TInkerGraph}} OLAP talking to {{TinkerGraph}} 
> OLTP? Well, this gets back to {{GraphComputer.RESULT_GRAPH}} and whether your 
> graph computer is operating over the real graph or a clone of it. However, I 
> think its just the same as TItan/Giraph-style.
> So what is this good for?
> * Drop all the "knows" edges.
> * Change all the date properties from {{java.util.Date}} to {{Long}}.
> * Infer all {{foaf}}-edges.
> * etc.
> Things to consider -- transactions.
> If we solve this cleanly, then that is truly the final "big hurdle" in the 
> {{GraphComputer}} story.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1070) Enable edge mutations in GraphComputer

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1070:

Fix Version/s: (was: 3.2.6)
   3.2.7

> Enable edge mutations in GraphComputer
> --
>
> Key: TINKERPOP-1070
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1070
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> Right now you can only mutate vertex properties. You CAN NOT add/delete 
> vertices nor add/delete edges. At least, there is no specification for the 
> semantics of this and thus, there is no consistent behavior between different 
> providers. This might be easy --- or it might be hard :).
> Make this work for TinkerGraph, Spark, and Giraph and then create test cases 
> for the semantics in {{GraphComputerTest}}.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1129) Make StarGraphGraphSONSerializer and connect it up with GraphFilter and GraphSONInputFormat

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1129:

Fix Version/s: (was: 3.2.6)
   3.2.7

> Make StarGraphGraphSONSerializer and connect it up with GraphFilter and 
> GraphSONInputFormat
> ---
>
> Key: TINKERPOP-1129
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1129
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, io
>Affects Versions: 3.2.5
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> Currently, only {{ScriptInputFormat}} and {{GryoInputFormat}} are able to 
> leverage {{GraphFilter}} "close to the metal." We should do the same for 
> {{GraphSONInputFormat}} via {{StarGraphGraphSONSerializer}}. It shouldn't be 
> that hard, just need to do it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-871) RuntimeStrategy as the general model for all such execution time rewrites/re-orders

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-871:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> RuntimeStrategy as the general model for all such execution time 
> rewrites/re-orders
> ---
>
> Key: TINKERPOP-871
> URL: https://issues.apache.org/jira/browse/TINKERPOP-871
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.7
>
>
> {{TraversalStrategies}} are used at compile time to translate a traversal 
> into a more optimal, graph system specific, or decorated traversal. These all 
> execute at compile time. However, we also have {{MatchAlgorithm}} which is 
> used by {{MatchStep}} to do runtime analysis and resort patterns accordingly. 
> I would like to make {{MatchAlgorithm}} implement {{RuntimeStrategy}} and 
> start to build out a collection of {{RuntimeStrategies}}. Where else could we 
> leverage runtime analysis:
> * {{OrStep}} and {{AndStep}} -- which pattern is filtering fastest? Do that 
> first.
> * {{MatchStep}} -- already using it with {{CountMatchAlgorithm}} and pattern 
> sorting.
> * ??? 
> ... can't think, there are probably more.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-819) Mapping Cardinality Interface

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-819:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Mapping Cardinality Interface
> -
>
> Key: TINKERPOP-819
> URL: https://issues.apache.org/jira/browse/TINKERPOP-819
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Minor
>  Labels: breaking
> Fix For: 3.2.7
>
>
> I think it would be handy (for some {{sack()}} work I'm doing on 
> merging/splitting sacks), but also in general as I've wanted this before 
> (can't remember why). I think we should add the following interfaces.
> {code}
> ManyToOneMapping (e.g. reducing barriers)
> OneToManyMapping (e.g. flatmap)
> OneToOneMapping (e.g. map, sideeffects)
> OneToOneOrNoneMapping (e.g. filter)
> {code}
> We can just rely on {{instanceof FlatMapStep}} or {{instanceof MapStep}} as 
> there are steps that are "map steps" but don't extend {{MapStep}}, but 
> instead {{AbstractStep}}. Either we make it so that all steps MUST extend 
> from {{FlatMapStep}}, {{MapStep}}, etc. or we can add the above interfaces.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1074) More contractual testing/specifications around Persist and ResultGraph.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1074:

Fix Version/s: (was: 3.2.6)
   3.2.7

> More contractual testing/specifications around Persist and ResultGraph.
> ---
>
> Key: TINKERPOP-1074
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1074
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> A {{ComputerResult}} references two objects: a graph and a memory. The graph 
> is the resultant computed graph and the memory contains all the sideEffect 
> data from the computation (if any).
> Right now, we have the following {{Persist}} options: {{NOTHING}}, 
> {{VERTEX_PROPERTIES}}, {{EDGES}}. We also have the following {{ResultGraph}} 
> options: {{ORIGINAL}}, {{NEW}}.
> * NOTHING + ORIGINAL = ComputerResult contains original graph reference.
> * NOTHING + NEW = ?? No test to force what this means! Should be 
> {{EmptyGraph.instance()}}.
> * VERTEX_PROPERTIES + ORIGINAL = ComputerResult contains original graph, but 
> the computed vertex properties have been "saved" to it. (no contractual test 
> cases here either!)
> * VERTEX_PROPERTIES + NEW = ComputerResult contains new graph with only 
> vertices and their properties.
> * EDGES + NEW = ComputerResult contains new graph with vertices, edges, and 
> their properties.
> * EDGES + ORIGINAL = ComputerResult contains original graph, but the computed 
> vertex properties and edges have been "saved" to it. (no contractual test 
> cases here either!)
> {{TinkerGraphComputer}} is the only system that supports all the above 
> configuration combinations. Add test cases to {{GraphComputerTest}} that 
> verify the behavior of all combinations.
> HOWEVER  -- should we really respect ORIGINAL+PERSIST? Most providers 
> will use {{BulkLoaderVertexProgram}} to write the computed graph back to the 
> original graph. If there are TWO ways of doing this, this seems bad? In fact, 
> the way that TinkerGraphComputer writes the computed graph back to the 
> original graph is nearly identical to how it BulkLoaderVertexProgram works. 
> Thus, I'm wondering if we simply get rid the concept of {{ResultGraph}} and 
> ONLY have {{Persist}}.
> * Persist.NOTHING: Returns the original graph in {{ComputerResult}}.
> * Persist.VERTEX_PROPERTIES: Returns a new graph with only vertices and 
> properties.
> * Persist.EDGES: Returns a new graph with vertices, edges, and their 
> properties.
> For in-memory graphs like {{TinkerGraph}}, "new graph" can mean the original 
> graph with the {{GraphView}} overlay. Thus, its not really a full copy of the 
> original graph. Moreover, Persist.NOTHING just garbage collects the GraphView 
> and thus, the original graph.
> --
> Next, what does {{Persist}} mean for memory? Remember, {{ComputerResult}} 
> also has a reference to sideEffect memory. What if you want to run a job, NOT 
> persist the graph, but persist the memory only. I think we should ALWAYS 
> assume memory persistence. For TinkerGraph, that means the the 
> ComputerResult.memory() has a HashMap of memory values. For Giraph/Spark, 
> that means that the {{Storage}} will always have resultant sideEffect data in 
> the output directory even if there is no graph.
> * {{NOTHING}}: persist memory and return the original graph.
> * {{VERTEX_PROPERTIES}}: persist memory and return new graph of just vertex 
> properties.
> * {{EDGES}}: persist memory and return new graph of vertex properties, and 
> edges.
> Decisions, decisions, decisions



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-966) Support reversible traversals in MatchStep (and respective MatchAlgorithms)

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-966:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Support reversible traversals in MatchStep (and respective MatchAlgorithms)
> ---
>
> Key: TINKERPOP-966
> URL: https://issues.apache.org/jira/browse/TINKERPOP-966
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> We currently do not support the reversing of a traversal. Thus,
> {code}
> g.V().match(
>   as("a").out("knows").as("b")
>   as("c").out("knows").as("a"))
> {code}
> will throw an exception saying that it can't compute the patterns. If we can 
> convert {{as("c").out("knows").as("a")}} to {{as("a").in("knows").as("c")}} 
> then this will work. Furthermore, we need a way to have two versions of a 
> traversal pattern available. For instance:
> {code}
> g.V().match(
>   as("a").out("knows").as("b")
>   as("a").out("friend").as("b"))
> {code}
> Given the above patterns, it is possible for both patterns to have a standard 
> and a "reversed-form" that can be selected dynamically given the 
> match-path-history and pattern statistics. Thus, we need a way to have all 
> four patterns able to be selected but once one of the two-pair is selected 
> for a traverser, it can't use the other.
> In short, we need {{TraversalHelper.reverse(Traversal)}} and 
> {{MathStep.MatchAlgorithm}} book-keeping data structures.
> cc/ [~mbroecheler]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-831) How should OLAP treat Collection objects? No contract is specified.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-831:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> How should OLAP treat Collection objects? No contract is specified.
> 
>
> Key: TINKERPOP-831
> URL: https://issues.apache.org/jira/browse/TINKERPOP-831
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.7
>
>
> Assume the following OLAP query:
> {code}
> g.V.group.by(label).by().by(order(local).by('name'))
> {code}
> The {{Map}} that is processed by {{GroupMapReduce}} 
> doesn't have "real vertices." For TinkerGraph/Spark/Giraph, we use 
> {{DetachedVertices}}. However, we don't have a specification for forcing this 
> on vendors.  We need a contract so its not "who knows?! -- pura vida 
> -- namaste -- comme ci, comme ça"



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (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 updated TINKERPOP-620:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> 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
> Fix For: 3.2.7
>
>
> 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
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1287) StarGraph has an overdose of Stream usage.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1287:

Fix Version/s: (was: 3.2.6)
   3.2.7

> StarGraph has an overdose of Stream usage.
> --
>
> Key: TINKERPOP-1287
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1287
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, structure
>Affects Versions: 3.2.0-incubating, 3.1.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Ted Wilmes
> Fix For: 3.2.7
>
> Attachments: g.V.out.out.count.svg, stage0.svg, stage1.svg, stage2.svg
>
>
> {{StarGraph}} is loaded with {{Stream}}-usage. Gutting streams from 
> TinkerGraph made it much faster. It would be good if we did the same thing 
> for {{StarGraph}}.
> This can go into tp31/ and upmerge to master/.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1141) HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a SideEffect in OLAP Traversal.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1141:

Fix Version/s: (was: 3.2.6)
   3.2.7

> HadoopRemoteAcceptor is overly complicated. Simplify with ComputerResult as a 
> SideEffect in OLAP Traversal.
> ---
>
> Key: TINKERPOP-1141
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1141
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: hadoop, process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> {{HadoopRemoteAcceptor}} is overly complicated. I think that instead of 
> making {{ComputerResult}} a value in the Console, we should just add 
> {{ComputerResult}} to the OLAP {{Traversal}}.
> {code}
> t = g.V().out().count()
> result = t.getSideEffects().get('~computerResult')
> {code}
> For most people, they will never use this as computer result memory is 
> already in the sideEffects. However, {{ComputerResult}} also has other 
> information like iteration, runtime, and graph.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-743) Support "barrier syntax" in step labels.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-743:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Support "barrier syntax" in step labels.
> 
>
> Key: TINKERPOP-743
> URL: https://issues.apache.org/jira/browse/TINKERPOP-743
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
>Priority: Minor
>  Labels: breaking
> Fix For: 3.2.7
>
>
> Here is a basic recommendation algorithm that we currently can not do in 
> match().
> {code}
> g.V(1).as('a').out('likes').aggregate('x'). // what does v[1] like
> in('likes').where(neq('a')).// who else likes those things 
> that are not v[1]
> out('likes').where(not(within('x')).// what do those people like that 
> v[1] doesn't already like
> groupCount()// count the number of times each 
> liked thing is seen
> {code}
> Why can't we do this in match()? Because we can not aggregate (well, we can, 
> but bare with me). The best we can do is:
> {code}
> g.V(1).match('a',
> as('a').out('likes').as('b'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',neq('b')),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> So what's the problem? The problem is that where('d',neq('b')) is only going 
> to make sure that the current 'd' is not equal to the current 'b'. Not the 
> aggregate of all b's. How do we solve this? Here is how we would "manually" 
> solve it using Kuppitz' latest idea of adding a clear()-step, where 
> clear('x') => sideEffect{it.sideEffects('x').clear()}
> {code}
> g.V(1).match('a',
> as('a').clear('{b}').out('likes').aggregate('{b}').as('b'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',not(within('{b}'))),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> However, suppose that we make "{ }" (set) and "[ ]" (list) special label 
> characters whereby the above is compiled to from the following:
> {code}
> g.V(1).match('a',
> as('a').out('likes').as('{b}'),
> as('b').in('likes').as('c'),
> as('c').out('likes').as('d'),
> where('d',not(within('{b}'))),
> where('a',neq('c'))).
> select('d').groupCount()
> {code}
> In essence, if an end variable is labeled with "{ }" that means aggregate to 
> set ("[ ]" could mean aggregate to list). The variable name inside the "{ }" 
> is then the "drain" of the CollectingBarrierStep -- i.e., the single object 
> emission post aggregation. Next, the as("{b}") syntax need not be limited to 
> match() where, in fact, the first query of this email could be written as:
> {code}
> g.V(1).as('a').out('likes').as('{x}').
> in('likes').where(neq('a')).
> out('likes').where(not(within('{x}')).
> groupCount()
> {code}
> Where does the clear() go in the above? It goes after the first StartStep 
> encountered moving "left." Thus, the previous compiles to the following:
> {code}
> g.V(1).as('a').clear('{x}').out('likes').aggregate('{x}').as('x')
> in('likes').where(neq('a')).
> out('likes').where(not(within('{x}')).
> groupCount()
> {code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1711) map(union(fold())) bug

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1711:

Fix Version/s: (was: 3.2.6)
   3.2.7

> map(union(fold())) bug
> --
>
> Key: TINKERPOP-1711
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1711
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.2.5
>Reporter: Robert Dale
>Assignee: Daniel Kuppitz
> Fix For: 3.2.7
>
>
> Actual:
> {code:java}
> gremlin> graph = TinkerFactory.createModern()
> ==>tinkergraph[vertices:6 edges:6]
> gremlin> g = graph.traversal()
> ==>graphtraversalsource[tinkergraph[vertices:6 edges:6], standard]
> gremlin> g.V().valueMap()
> ==>[name:[marko],age:[29]]
> ==>[name:[vadas],age:[27]]
> ==>[name:[lop],lang:[java]]
> ==>[name:[josh],age:[32]]
> ==>[name:[ripple],lang:[java]]
> ==>[name:[peter],age:[35]]
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[[],vadas]
> ==>[lop,[java]]
> ==>[[],josh]
> ==>[ripple,[java]]
> ==>[[],peter]
> {code}
> Expected:
> {code:java}
> gremlin> g.V().map(union(values('name'), values('lang').fold()).fold())
> ==>[marko,[]]
> ==>[vadas,[]]
> ==>[lop,[java]]
> ==>[josh,[]]
> ==>[ripple,[java]]
> ==>[peter,[]]
> {code}
> List reference:  
> https://groups.google.com/forum/#!topic/gremlin-users/L_fESS6ta0A



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-963) SubgraphTraversalAnalyzer to determine what is really required from a traversal.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-963:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> SubgraphTraversalAnalyzer to determine what is really required from a 
> traversal.
> 
>
> Key: TINKERPOP-963
> URL: https://issues.apache.org/jira/browse/TINKERPOP-963
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> This idea is dependent on the work in TINKERPOP3-962 being complete.
> The idea is that there should be a {{SubgraphTraversalAnalyzer}}-type step 
> that for a {{traversal}} returns a 
> {{Pair,Traversal>}} that defines two 
> "filters" that contain the subgraph that the traversal will execute in.
> For instance.
> {code}
> g.V().hasLabel("person").out("pets").hasLabel("dog")
> {code}
> {{SubgraphTraversalAnalyzer}} would return
> {code}
> Pair.with(
>   hasLabel("person","dog"),
>   hasLabel("pets"))
> {code}
> The difficulty with this ticket is that TinkerPop does NOT make any 
> assumptions about a schema. For instance, if the user did this:
> {code}
> g.V().hasLabel("person").out("pets")
> {code}
> Then the best we could return is:
> {code}
> Pair.with(
>   identity(),
>   hasLabel("pets"))
> {code}
> cc/ [~mbroecheler]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1187) Create a GraphComputer Tutorial

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1187:

Fix Version/s: (was: 3.2.6)
   3.2.7

> Create a GraphComputer Tutorial
> ---
>
> Key: TINKERPOP-1187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1187
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.1.1-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> We should create a GraphComputer tutorial that discusses:
> 1. GraphComputer, Memory, and VertexPrograms.
> 2. Explains how Traversals are compiled to TraversalVertexPrograms.
> 3. The mechanics of a TraversalVertexProgram.
> 4. How to write your own VertexProgram.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1687) Record metrics around how long it gremlin script executions sit in executor queue waiting to be executed.

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1687:

Fix Version/s: (was: 3.2.6)
   3.2.7

> Record metrics around how long it gremlin script executions sit in executor 
> queue waiting to be executed.
> -
>
> Key: TINKERPOP-1687
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1687
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.2.4
>Reporter: David Pitera
>Priority: Minor
>  Labels: breaking
> Fix For: 3.2.7
>
>
> The issue will be breaking because I will be moving the MetricManager into 
> the gremlin-core project from the gremlin-server project for easier use 
> across the project. Therefore whoever is using the MetricManager will need to 
> update their location from where they grab it.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-889) Support for partitioned vertices in GraphComputer

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-889:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Support for partitioned vertices in GraphComputer
> -
>
> Key: TINKERPOP-889
> URL: https://issues.apache.org/jira/browse/TINKERPOP-889
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Matthias Broecheler
>Assignee: Marko A. Rodriguez
>  Labels: breaking
> Fix For: 3.2.7
>
>
> Most natural graphs have scale free distributions which means that some 
> vertices in the graph have significantly more incident edges than others. On 
> large graphs, it is therefore not uncommon to encounter vertices whose 
> adjacency list is to large to be accommodated efficiently by a single machine 
> (due to lack of sufficient memory or because they create a hotspot).
> Other graph computing frameworks have successfully addressed this "supernode 
> problem" by partitioning the vertex's adjacency list and processing each 
> subset of the adjacency list separately because merging the results (e.g. 
> counting edges in each subset and then adding those values to get the total 
> degree). TinkerPop should implement such functionality and allow partitioned 
> vertex adjacency lists in the input to GraphComputer. This is a critical 
> feature to make TP applicable to large graph computations.
> This can be implemented fairly easily for local messages using the message 
> combiners. Global messages can be tricky however. See also TINKERPOP3-383. 
> This has been partially implemented in Titan's Fulgora package 
> (https://github.com/thinkaurelius/titan/tree/titan10/titan-core/src/main/java/com/thinkaurelius/titan/graphdb/olap).



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-1098) Local Filters

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-1098:

Fix Version/s: (was: 3.2.6)
   3.2.7

> Local Filters
> -
>
> Key: TINKERPOP-1098
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1098
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Daniel Kuppitz
> Fix For: 3.2.7
>
>
> We should provide local filter steps. Currently, if you want to filter 
> elements from paths or lists (or maps?), you have to do 
> {{unfold().filter().fold()}}.
> Not sure if that only affects {{filter()}}, or also {{has()}}, {{hasNot()}}, 
> {{where()}}, ...



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-882) Develop a less error prone way for rewriting strategies

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-882:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Develop a less error prone way for rewriting strategies
> ---
>
> Key: TINKERPOP-882
> URL: https://issues.apache.org/jira/browse/TINKERPOP-882
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> When someone writes a {{TraversalStrategy}} it is of the nature:
> {code}
> if(step instanceof SelectStep && ((SelectStep)step).getLocalChildren().size() 
> > 1) {
>   TraversalHelper.insertStep(new IdentityStep(), step, traversal);
> }
> {code}
> It can start to get hairy looking fast. It would be great if we could study 
> the strategies we have thus far and see if there are patterns we can extract 
> encapsulate such behaviors in new methods in {{TraversalHelper}}. I don't 
> have any good ideas on how to do this, but I think we need it. My only 
> thought was a "regular expression" language for our traversals so we can 
> pattern match ON the traversal. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-669) Consider Required TraversalStrategies

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-669:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Consider Required TraversalStrategies
> -
>
> Key: TINKERPOP-669
> URL: https://issues.apache.org/jira/browse/TINKERPOP-669
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.0.2-incubating
>Reporter: stephen mallette
>Assignee: Marko A. Rodriguez
>Priority: Minor
> Fix For: 3.2.7
>
>
> As we now execute the Gremln process suite with and without strategies 
> applied, it became apparent that some strategies are simply "required".  See:
> https://github.com/apache/incubator-tinkerpop/blob/0d239c05638269e6cd5c7af7bd3c61a50627d0bc/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/TinkerGraphNoStrategyComputerProvider.java#L41-L46
> https://github.com/apache/incubator-tinkerpop/blob/0d239c05638269e6cd5c7af7bd3c61a50627d0bc/tinkergraph-gremlin/src/test/java/org/apache/tinkerpop/gremlin/tinkergraph/process/TinkerGraphNoStrategyProvider.java#L42
> Not sure what this means in the grand scheme of things. A few things that 
> feel weird or require more thought:
> 1. Kinda weird that a {{Traversal}} requires any strategies at all to execute.
> 2. Kinda weird that a {{Step}} should know anything about strategies as is 
> the case with {{ConjunctionStrategy}} for example.
> 3. If required strategies are expected then should those required strategies 
> be somewhere more prominently maintained/documented/etc than just being 
> relegated to the test suite
> Not sure anything really needs to change here, just wanted to create an issue 
> for future thought.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-940) Convert LocalTraversals to MatchSteps in OLAP and Solve the StarGraph Problem

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-940:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> Convert LocalTraversals to MatchSteps in OLAP and Solve the StarGraph Problem
> -
>
> Key: TINKERPOP-940
> URL: https://issues.apache.org/jira/browse/TINKERPOP-940
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>Assignee: Marko A. Rodriguez
> Fix For: 3.2.7
>
>
> This fails in OLAP.
> {code}
> g.V().match(
>   as('a').out('sungBy').as('b'),
>   as('a').out('writtenBy').as('b')).
> select('a','b').by('name')
> {code}
> However, this passes:
> {code}
> g.V().match(
>   as('a').out('sungBy').as('b'),
>   as('a').out('writtenBy').as('b'),
>   as('a').values('name').as('c'),
>   as('b').values('name').as('d')).
> select('c','d')
> {code}
> Can all "local star graph" OLAP problems be strategized into MatchSteps? It 
> would be a decoration strategy of some sort [~dkuppitz]



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (TINKERPOP-967) Support nested-repeat() structures

[stephen mallette (JIRA)]

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

stephen mallette updated TINKERPOP-967:
---
Fix Version/s: (was: 3.2.6)
   3.2.7

> 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
> Fix For: 3.2.7
>
>
> 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
(v6.4.14#64029)