Re: [VOTE] TinkerPop 3.4.4 Release

[Daniel Kuppitz]

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.4.4-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.4-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.4 (apache-tinkerpop-3.4.4-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.4.4 ... OK
* checking source files ... OK
* building project ... OK


VOTE +1

Cheers,
Daniel


On Mon, Oct 14, 2019 at 12:02 PM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.4.4 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.4/
>
> The source distribution is provided by:
> apache-tinkerpop-3.4.4-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.4.4-bin.zip
> apache-tinkerpop-gremlin-server-3.4.4-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.4.4/ (user docs)
> http://tinkerpop.apache.org/docs/3.4.4/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.4.4/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.4.4/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.4.4/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.4.4/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.4.4
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.4.4/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday (October
> 17, 2019) at 3:00pm EST.
>
> Note that I had to push an extra commit after the tag to get
> validate-distribution.sh working properly. Please pull the latest on tp34
> if you plan to use that in your review.
>
> My vote is +1.
>
> Thank you very much,
>
> Stephen
>

Re: [VOTE] TinkerPop 3.3.9 Release

[Daniel Kuppitz]

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.3.9-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.9-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.9 (apache-tinkerpop-3.3.9-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.3.9 ... OK
* checking source files ... OK
* building project ... OK


I took a closer look at the docs and found some issues.


   - http://tinkerpop.apache.org/docs/3.3.9/reference/#addedge-step
   List point number 5 below the code box has a minor formatting error.

   - http://tinkerpop.apache.org/docs/3.3.9/reference/#graph-step
   List point number 1 below the second code box has a minor formatting
   error.

   - http://tinkerpop.apache.org/docs/3.3.9/reference/#none-step
   Formatting error in "Additional References".

   - http://tinkerpop.apache.org/docs/3.3.9/reference/#simplepath-step
   Empty result for the last two queries. An empty result is correct, yet
   it looks confusing, we should probably extend this section a little bit.

   - http://tinkerpop.apache.org/docs/3.3.9/reference/#to-step
   The description is not quite right. to() is both - a step and a
   modulator.


All of these issues are non-blocking (and probably not new), I just wanted
to have them mentioned, thus ...

VOTE +1

Cheers,
Daniel


On Mon, Oct 14, 2019 at 5:01 AM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.3.9 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.9/
>
> The source distribution is provided by:
> apache-tinkerpop-3.3.9-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.3.9-bin.zip
> apache-tinkerpop-gremlin-server-3.3.9-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.9/ (user docs)
> http://tinkerpop.apache.org/docs/3.3.9/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.3.9/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.3.9/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.3.9/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.3.9/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.3.9
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.3.9/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday (October
> 17, 2019) at 8:00am EST.
>
> My vote is +1.
>
> Thank you very much,
>
> Stephen
>

Re: [VOTE] TinkerPop 3.4.3 Release

[Daniel Kuppitz]

Looks like you're on Mac. This should help:
https://apple.stackexchange.com/questions/69223/how-to-replace-mac-os-x-utilities-with-gnu-core-utilities

Cheers,
Daniel


On Wed, Aug 7, 2019 at 1:12 PM Joshua Shinavier  wrote:

> Thanks. No luck yet, but did also have to change this:
>
> COMMITTERS=$(curl -Ls
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> | tee ${TMP_DIR}/KEYS | grep -Po '(?<=<)[^<]*(?=@apache.org>)' | uniq)
>
>
> to this:
>
> COMMITTERS=$(curl -Ls
> https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> | tee ${TMP_DIR}/KEYS | perl -nle 'print $& while m{(?<=<)[^<]*(?=@
> apache.org>)}g' | uniq)
>
> as grep -P is not supported in my environment.
>
> Josh
>
>
> On Wed, Aug 7, 2019 at 10:49 AM Stephen Mallette 
> wrote:
>
> > I think you just need to import our public keys. just download this:
> >
> > https://dist.apache.org/repos/dist/dev/tinkerpop/KEYS
> >
> > and then:
> >
> >  $ gpg --import KEYS
> >
> > i think that's it anyway.
> >
> > On Wed, Aug 7, 2019 at 1:43 PM Joshua Shinavier 
> wrote:
> >
> > > Thanks, Stephen. I tried the script from the 3.4.3 tag, and ran into
> the
> > > following. What am I doing wrong?
> > >
> > >
> > > $ bin/validate-distribution.sh 3.4.3
> > >
> > >
> > > Validating binary distributions
> > >
> > >
> > > usage: grep [-abcDEFGHhIiJLlmnOoqRSsUVvwxZ] [-A num] [-B num] [-C[num]]
> > >
> > > [-e pattern] [-f file] [--binary-files=value] [--color=when]
> > >
> > > [--context[=num]] [--directories=action] [--label] [--line-buffered]
> > >
> > > [--null] [pattern] [file ...]
> > >
> > > (23) Failed writing body
> > >
> > > * downloading Apache TinkerPop Gremlin
> > > (apache-tinkerpop-gremlin-console-3.4.3-bin.zip)... OK
> > >
> > > * validating signatures and checksums ...
> > >
> > >   * PGP signature ... failed
> > >
> > >
> > >
> > > On Wed, Aug 7, 2019 at 10:25 AM Stephen Mallette  >
> > > wrote:
> > >
> > > > You can use:
> > > >
> > > >
> > > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/master/bin/validate-distribution.sh
> > > >
> > > >
> > > > it does "everything" - just make sure to run it from the branch on
> > which
> > > > the release was done.
> > > >
> > > > On Wed, Aug 7, 2019 at 1:19 PM Joshua Shinavier 
> > > wrote:
> > > >
> > > > > Humble +1 from me. Cool logo. Daniel, what script are you using for
> > > > > validating the distribution?
> > > > >
> > > > > Josh
> > > > >
> > > > > On Wed, Aug 7, 2019 at 7:35 AM Robert Dale 
> > wrote:
> > > > >
> > > > > > Best durn lookin' docs ever!
> > > > > > VOTE +1
> > > > > >
> > > > > > Robert Dale
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 7, 2019 at 7:39 AM Daniel Kuppitz 
> > > wrote:
> > > > > >
> > > > > > > Distribution validation is looking good.
> > > > > > >
> > > > > > > Validating binary distributions
> > > > > > >
> > > > > > > * downloading Apache TinkerPop Gremlin
> > > > > > > (apache-tinkerpop-gremlin-console-3.4.3-bin.zip)... OK
> > > > > > > * validating signatures and checksums ...
> > > > > > >   * PGP signature ... OK
> > > > > > >   * SHA512 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
> > > > > > >
> > &

Re: [VOTE] TinkerPop 3.3.8 Release

[Daniel Kuppitz]

Distribution validation looks good.

Validating binary distributions

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.3.8-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.8-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.8 (apache-tinkerpop-3.3.8-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.3.8 ... OK
* checking source files ... OK
* building project ... OK


Skimmed over the docs, no issues found.

VOTE +1

Cheers,
Daniel


On Mon, Aug 5, 2019 at 11:35 AM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.3.8 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.8/
>
> The source distribution is provided by:
> apache-tinkerpop-3.3.8-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.3.8-bin.zip
> apache-tinkerpop-gremlin-server-3.3.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.3.8/ (user docs)
> http://tinkerpop.apache.org/docs/3.3.8/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.3.8/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.3.8/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.3.8/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.3.8/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.3.8
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.3.8/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Thursday (August
> 8, 2019) at 2:30pm EST.
>
> My vote is +1.
>

Re: [VOTE] TinkerPop 3.4.3 Release

[Daniel Kuppitz]

Distribution validation is looking good.

Validating binary distributions

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.4.3-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.3-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.3 (apache-tinkerpop-3.4.3-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.4.3 ... OK
* checking source files ... OK
* building project ... OK


Skimmed over the docs, with focus on common problem areas, no issues found.

VOTE +1

Cheers,
Daniel



On Tue, Aug 6, 2019 at 4:11 AM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.4.3 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.3/
>
> The source distribution is provided by:
> apache-tinkerpop-3.4.3-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.4.3-bin.zip
> apache-tinkerpop-gremlin-server-3.4.3-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.4.3/ (user docs)
> http://tinkerpop.apache.org/docs/3.4.3/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.4.3/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.4.3/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.4.3/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.4.3/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.4.3
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.4.3/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (August 9,
> 2019) at 7am EST.
>
> My vote is +1.
>

Re: [DISCUSS] exp4j

[Daniel Kuppitz]

I agree. Calculators are the Hello World of ANTLR, thus it will be pretty
easy to make our own lib, and it will be super easy to add new functions
(e.g. if someone asks for STDDEV and PERCENTILE, it's really just a few
lines of code for us).
>From a user perspective, there would be no difference compared to what we
have now, everything would be string-based.

Cheers,
Daniel


On Tue, Jul 30, 2019 at 4:34 AM Marko Rodriguez 
wrote:

> Hi,
>
> I think we should create our own math library. We will need it for mm-ADT,
> Kuppitz has the ANTLR chops down, …
>
> Marko.
>
> http://rredux.com 
>
>
>
>
> > On Jul 30, 2019, at 5:31 AM, Stephen Mallette 
> wrote:
> >
> > Kuppitz just answered a question on gremlin-users that involved math()
> > which is backed by exp4j. That made me recall that exp4j is technically
> not
> > maintained anymore. While it is a stable library it seems a bit worrisome
> > that we're a bit dead-ended there. The README currently says that the
> > author is looking for volunteers to replace him and it's been that way
> for
> > a while.
> >
> > I"m not sure what the alternatives are to exp4j and I imagine that
> > alternatives might come with expression syntax changes which wouldn't be
> > good.
> >
> > Anyone have any thoughts on this?
>
>

Re: [DISCUSS] code freeze 3.3.8/3.4.3

[Daniel Kuppitz]

No changes to my bio required.

Cheers,
Daniel


On Fri, Jul 26, 2019 at 7:29 AM Stephen Mallette 
wrote:

> Code freeze for the tp34 and tp33 branches goes into effect at close of
> business today. The master branch remains open for business. We have a few
> PRs that need reviews still:
>
> https://github.com/apache/tinkerpop/pull/1165
> https://github.com/apache/tinkerpop/pull/1166
> https://github.com/apache/tinkerpop/pull/1167
> https://github.com/apache/tinkerpop/pull/1169
>
> As usual, please use this thread for release related issues during this
> week. If someone wants to pick up release manager duties please let me
> know.
>
> Also note that, given our slightly revised policy around the Contributor
> Listing we now call for updates to bios during code freeze week. So, for
> committers and/or PMC members, your name is listed on the TinkerPop home
> page in the Contributor List[1] with your "bio". If you are active on the
> project, your "bio" reflects what you have been working on and what you
> expect to be working on with respect to TinkerPop for recent times (i.e.
> for the previous six months and the following six months). If you are
> currently inactive on the project, your "bio" reflects the full scope of
> all your contributions throughout your active periods. You can refer to the
> contributor listing policy[2] for full details.
>
> Please take a moment to update your bio directly in Git[3] or, if you would
> prefer, please reply to this post with your bio update and it will be added
> for you. If no changes are required, please reply to this email to confirm
> that this is the case.
>
> [1] http://tinkerpop.apache.org/#contributors
> [2]
> http://tinkerpop.apache.org/docs/current/dev/developer/#contributor-listing
> [3]
> https://github.com/apache/tinkerpop/blob/master/docs/site/home/index.html
>

[jira] [Closed] (TINKERPOP-1084) Branch option tokens should be allowed to be traversals.

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1084.
-
   Resolution: Fixed
Fix Version/s: 3.5.0
   3.4.3
   3.3.8

> Branch option tokens should be allowed to be traversals.
> 
>
> Key: TINKERPOP-1084
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1084
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.8, 3.4.3, 3.5.0
>
>
> It would be cool if we could do this:
> {code}
> g.V().hasLabel("person").
>   choose(values("age")).
> option(is(lt(28)), constant("low")).
> option(is(between(29,30)), constant("medium"))
> option(none,constant("high"))
> {code}
> That is, "option tokens" can be traversals and if they are evaluate the 
> traversal as a predicate.



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

[jira] [Resolved] (TINKERPOP-2230) match() step unexpected behaviours

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz resolved TINKERPOP-2230.
---
   Resolution: Fixed
Fix Version/s: 3.5.0
   3.4.3
   3.3.8

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>    Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
> Fix For: 3.3.8, 3.4.3, 3.5.0
>
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



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

[jira] [Work started] (TINKERPOP-1084) Branch option tokens should be allowed to be traversals.

[Daniel Kuppitz (JIRA)]

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

Work on TINKERPOP-1084 started by Daniel Kuppitz.
-
> Branch option tokens should be allowed to be traversals.
> 
>
> Key: TINKERPOP-1084
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1084
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>    Assignee: Daniel Kuppitz
>Priority: Major
>
> It would be cool if we could do this:
> {code}
> g.V().hasLabel("person").
>   choose(values("age")).
> option(is(lt(28)), constant("low")).
> option(is(between(29,30)), constant("medium"))
> option(none,constant("high"))
> {code}
> That is, "option tokens" can be traversals and if they are evaluate the 
> traversal as a predicate.



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

[jira] [Assigned] (TINKERPOP-1084) Branch option tokens should be allowed to be traversals.

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz reassigned TINKERPOP-1084:
-

Assignee: Daniel Kuppitz

> Branch option tokens should be allowed to be traversals.
> 
>
> Key: TINKERPOP-1084
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1084
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.1.0-incubating
>Reporter: Marko A. Rodriguez
>    Assignee: Daniel Kuppitz
>Priority: Major
>
> It would be cool if we could do this:
> {code}
> g.V().hasLabel("person").
>   choose(values("age")).
> option(is(lt(28)), constant("low")).
> option(is(between(29,30)), constant("medium"))
> option(none,constant("high"))
> {code}
> That is, "option tokens" can be traversals and if they are evaluate the 
> traversal as a predicate.



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

[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2230:
---

It will most likely be part of 3.3.8 and 3.4.3.

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



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

[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2230:
---

To me it looked like the implementation made the assumption that patterns are 
always circular (e.g. you can pick a random start label and from there you can 
reach any other label). Also, the user-defined start step (the start step of 
your first pattern) was never moved, so if you came up with pre-sorted solvable 
sequence, you wouldn't have run into an error.

Now, bad things started to happen if there's a start label that is never used 
as an end label. The start step discovery algorithm didn't force this child 
pattern to be pushed to the top (and thus define the ultimate start label). 
Hence, you sometimes got the unsolvable pattern error, although all child 
patterns as a whole would have produced a valid pattern (if only the start step 
would have been be right).

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>    Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



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

Re: [VOTE] TinkerPop 3.4.2 Release

[Daniel Kuppitz]

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.4.2-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.2-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.2 (apache-tinkerpop-3.4.2-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.4.2 ... OK
* checking source files ... OK
* building project ... OK


VOTE +1


On Tue, May 28, 2019 at 1:34 PM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.4.2 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.2/
>
> The source distribution is provided by:
> apache-tinkerpop-3.4.2-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.4.2-bin.zip
> apache-tinkerpop-gremlin-server-3.4.2-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.4.2/ (user docs)
> http://tinkerpop.apache.org/docs/3.4.2/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.4.2/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.4.2/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.4.2/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.4.2/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.4.2
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.4.2/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Firday (May 31,
> 2019) at 4:30pm EST.
>
> My vote is +1.
>
> Thank you very much,
>
> Stephen
>

Re: [VOTE] TinkerPop 3.3.7 Release

[Daniel Kuppitz]

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.3.7-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.7-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.7 (apache-tinkerpop-3.3.7-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.3.7 ... OK
* checking source files ... OK
* building project ... OK


VOTE +1

On Tue, May 28, 2019 at 8:28 AM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.3.7 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.7/
>
> The source distribution is provided by:
> apache-tinkerpop-3.3.7-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.3.7-bin.zip
> apache-tinkerpop-gremlin-server-3.3.7-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.7/ (user docs)
> http://tinkerpop.apache.org/docs/3.3.7/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.3.7/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.3.7/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.3.7/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.3.7/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.3.7
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.3.7/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (May 31,
> 2019) at 11:30am EST.
>
> My vote is +1.
>
> Thank you very much,
> Stephen
>

[jira] [Commented] (TINKERPOP-2230) match() step unexpected behaviours

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2230:
---

I think I solved it. It seems that the internal sorting is not causing any 
issues, but the determination of the start step can screw things up. Running 
the full integration test suite right now. If everything passes, I'll pus the 
PR out as soon as the branches are open for development again.

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



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

[jira] [Assigned] (TINKERPOP-2230) match() step unexpected behaviours

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz reassigned TINKERPOP-2230:
-

Assignee: Daniel Kuppitz

> match() step unexpected behaviours
> --
>
> Key: TINKERPOP-2230
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2230
> Project: TinkerPop
>  Issue Type: Bug
>Affects Versions: 3.4.1
>Reporter: Fabio Lorenzi
>    Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: gremlin
>
> On the well known software graph:
> {code:java}
> gremlin> g.V().match(
> ..1> __.as('a').out('knows').as('b'),
> ..2> __.as('b').out('created').as('c'))
> ==>[a:v[1],b:v[4],c:v[5]]
> ==>[a:v[1],b:v[4],c:v[3]]
> gremlin> g.V().match(
> ..1> __.as('b').out('created').as('c'),
> ..2> __.as('a').out('knows').as('b'))
> The provided match pattern is unsolvable: [[MatchStartStep(a), 
> VertexStep(OUT,[knows],vertex), MatchEndStep(b)], [MatchStartStep(b), 
> VertexStep(OUT,[created],vertex), MatchEndStep(c)]]
> {code}
> with the second one being solvable as well (I think). (?)
> Quoting [~dkuppitz]:
> "I just noticed that the error message of my failing traversal actually 
> contains a solvable form of patterns. It's really confusing; if you want, 
> create a Jira ticket for that issue, perhaps someone dares to analyze that 
> crazy code"
> please see 
> [this|https://stackoverflow.com/questions/56218188/match-clause-is-unsolvable-behavior-is-not-clear/56260508#56260508]
>  for more information.



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

Re: Type predicates (TP3 feature suggestion)

[Daniel Kuppitz]

+1 to have it as a predicate.

Also, it may seem tempting to support as many types as possible, but I
don't think we need that. Whenever I was in need of a type-check, I usually
had to figure out if the element is a vertex or an edge. Hence, a small set
of predefined types is probably good enough: Vertex, Edge, Property

Chers,
Daniel


On Tue, May 28, 2019 at 3:39 AM Stephen Mallette 
wrote:

> I've often thought of this feature more as a filter step than a predicate,
> but I suppose is() would work - I'd be curious to know what Daniel
> thinks...
>
> > TinkerPop 3 type system depends on the implementation, but there are some
> common types like Vertex, Edge, Map, List, String...
>
> I'm not sure how we want to go about providing the available types we could
> test against. I would imagine that they should be bound to the
> GraphSON/GraphBinary types somehow and should be extensible to provider
> types. If this sort of feature were to release without the latter, it won't
> long before the questions start coming in about "how do I check for a Point
> type?" or whatever.
>
> > outE().inV().path().unfold().is( type(Type.vertex) )
>
> Of all your examples, this is the one that I feel users probably come
> entangled with the most.
>
> > This requirement is actual for Cypher for Gremlin.
>
> I think this feature request has wider applicability than just
> translationwe have junky workarounds for type testing. I think that I'd
> like to see this change in 3.5.0. Let's see where the discussion goes as to
> exactly how it would work.
>
> On Mon, May 27, 2019 at 9:49 AM Dmitry Novikov 
> wrote:
>
> > Hello,
> >
> > I am aware that all of this will be improved in TinkerPop 4.
> >
> > Suggestion to introduce type predicates in TinkerPop 3:
> >
> > `...is(P.vertexType())...` or `...is(P.type(Type.vertex))...`
> >
> > with imports:
> >
> > `...is(vertexType())...` or `...is(P.type(vertex))...`
> >
> > TinkerPop 3 type system depends on the implementation, but there are some
> > common types like Vertex, Edge, Map, List, String...
> >
> > Depending on the type, different steps are required to perform similar
> > operations. For example, access by index:
> >
> > * `values(i)` to get property from vertex or edge
> > * `select(i)` to get value from map
> >
> > In complex traversals, it might be complicated to track type. This might
> > be improved by introducing type predicates:
> >
> > `...select('unknown').choose(mapType(), select('p'), values('p'))`
> >
> > Another use case - filter path elements. For example, getting all
> vertices
> > from path with mixed order of elements
> > `g.V().limit(1).out().out().inE().outV().path().as('myPath)` is not
> > trivial  task. This could be achieved by:
> >
> > `...select('myPath').unfold().is(vertexType())`
> >
> > Some steps depend on type:
> >
> > `g.V().values('prop1').max()` will fail with `java.lang.Integer cannot be
> > cast to java.lang.String` if `prop1` has different types. This could be
> > addressed:
> >
> > `g.V().values('prop1').is(numericType()).max()`
> >
> > This requirement is actual for Cypher for Gremlin. I am very interested
> to
> > know if this requirement is language translation specific, or have other
> > use cases.
> >
> > Please share your opinion on this.
> >
> > Regards,
> > Dmitry
> >
> >
>

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2220:
---

{quote}we'd be processing *v[6]* twice at _depth=3_, only to later dedup the 
duplicate pairs created from the double traversal{quote}

You are saying that you want to deduplicate the pair, but in your query, you 
deduplicate the vertex.

{code}
// what you want
g.V(1).repeat(identity().as("incoming").project("d","v").by(loops()).by(identity()).dedup().aggregate("pairs").select("incoming").out()).cap("pairs")
 // what you bring up as a non-working example
g.V(1).repeat(identity().as("incoming").project("d","v").by(loops()).by(identity()).aggregate("pairs").select("incoming").out().dedup()).cap("pairs")
{code}

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2220:
---

Just had another idea on how to explain it. Instead of {{dedup()}} let's just 
use a filter lambda that follows the same rules (and prints some debug 
messages):

{code}
gremlin> dedupLambda = {
..1>   element = it.get()
..2>   step = it.getStepId()
..3>   if ((m = (step =~ /[0-9]+\.[0-9]+\.[0-9]+\(\)/)).find()) {
..4> step = m.group()
..5>   }
..6>   seen = memory[step]?.contains(element)
..7>   memory[step] = (memory[step] ?: []) + [element]
..8>   println "${element} seen at step ${step}: ${seen ? 'yes (filter it)' 
: 'no (let it pass)'}"
..9>   return !seen
.10> }
==>groovysh_evaluate$_run_closure1@67514bdd
gremlin> 
gremlin> memory = [:] ; g.V().filter(dedupLambda).filter(dedupLambda).count()
v[1] seen at step 1.0.0(): no (let it pass)
v[1] seen at step 2.0.0(): no (let it pass)
v[2] seen at step 1.0.0(): no (let it pass)
v[2] seen at step 2.0.0(): no (let it pass)
v[3] seen at step 1.0.0(): no (let it pass)
v[3] seen at step 2.0.0(): no (let it pass)
v[4] seen at step 1.0.0(): no (let it pass)
v[4] seen at step 2.0.0(): no (let it pass)
v[5] seen at step 1.0.0(): no (let it pass)
v[5] seen at step 2.0.0(): no (let it pass)
v[6] seen at step 1.0.0(): no (let it pass)
v[6] seen at step 2.0.0(): no (let it pass)
==>6
gremlin> memory = [:] ; g.V().repeat(filter(dedupLambda)).times(2).count()
v[1] seen at step 1.0.0(): no (let it pass)
v[1] seen at step 1.0.0(): yes (filter it)
v[2] seen at step 1.0.0(): no (let it pass)
v[2] seen at step 1.0.0(): yes (filter it)
v[3] seen at step 1.0.0(): no (let it pass)
v[3] seen at step 1.0.0(): yes (filter it)
v[4] seen at step 1.0.0(): no (let it pass)
v[4] seen at step 1.0.0(): yes (filter it)
v[5] seen at step 1.0.0(): no (let it pass)
v[5] seen at step 1.0.0(): yes (filter it)
v[6] seen at step 1.0.0(): no (let it pass)
v[6] seen at step 1.0.0(): yes (filter it)
==>0
{code}

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2220:
---

{{dedup()}} is a {{FilterStep}}. Think about it, {{repeat(whatever).times(2)}} 
is supposed to emit whatever is left after the 2nd iteration. For 
{{repeat(dedup()).times(2)}} there's just nothing left in the stream as every 
element gets filtered in the 2nd iteration.

{code}
gremlin> g.V().repeat(dedup()).times(2).count()
==>0
gremlin> g.V().repeat(dedup()).emit().times(2).count()
==>6
{code}

If you emit all elements after each iteration, you'll get all the survivors 
from iteration 1. Does it make any more sense now?

It's not the same as {{dedup().dedup()}} as this only ensures uniqueness at two 
different steps in the traversal. And because it's not the same, 
{{RepeatUnrollStrategy}} won't do anything if it finds a {{DedupStep}}.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Closed] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2220.
-
Resolution: Not A Bug

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Comment Edited] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz edited comment on TINKERPOP-2220 at 5/17/19 5:10 PM:


The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like 
{{simplePath}} ensures that no element appears twice on the current path, 
{{repeat(dedup())}} ensures that no element is visited twice within the 
repetition.

{code}
gremlin> g.V(1).repeat(both().simplePath()).emit().path()
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4]]
==>[v[1],v[3],v[4]]
==>[v[1],v[3],v[6]]
==>[v[1],v[4],v[5]]
==>[v[1],v[4],v[3]]
==>[v[1],v[3],v[4],v[5]]
==>[v[1],v[4],v[3],v[6]]
{code}

Note, how the two longest paths visit {{v[5]}} and {{v[6]}} in the end 
(although these 2 vertices were already seen in shorter paths. Now watch this:

{code}
gremlin> g.V(1).repeat(both().simplePath().dedup()).emit().path()
==>[v[1],v[3]]
==>[v[1],v[2]]
==>[v[1],v[4]]
==>[v[1],v[3],v[6]]
==>[v[1],v[4],v[5]]
{code}

{{dedup()}} inside {{repeat()}} makes sure that this doesn't happen. In other 
cases, you don't really need to worry about deduplication; if two traversers 
hit the same element, they will merge. Thus, from a performance and memory 
perspective, it makes no difference if an element appears once or a thousand 
times within {{repeat()}}.


was (Author: dkuppitz):
The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like 
{{simplePath}} ensures that no element appears twice on the current path, 
{{repeat(dedup())}} ensures that no element is visited twice within the 
repetition.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

[jira] [Commented] (TINKERPOP-2220) Dedup inside Repeat Produces 0 results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2220:
---

The meaning of {{dedup()}} inside {{repeat()}} is a little different. Just like 
{{simplePath}} ensures that no element appears twice on the current path, 
{{repeat(dedup())}} ensures that no element is visited twice within the 
repetition.

> Dedup inside Repeat Produces 0 results
> --
>
> Key: TINKERPOP-2220
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2220
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.0
>Reporter: Rahul Chander
>Priority: Major
>
> Testing against the Tinkerpop Modern graph dataset, I ran this query:
> {code:java}
> g.V().repeat(__.dedup()).times(2).count()
> {code}
> which should essentially be the same as running dedup twice. It produced 0 
> results, while dedup twice produced the correct 6.
>  
>  
>  



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

Re: N-Tuples, Pointers, Data Model Interfaces, and Bytecode Instructions

[Daniel Kuppitz]

>
> it is theoretically possible to provide a service of this nature with TP4.


Theoretically yes, practically no. There are too many things to consider
when it comes to modeling decisions. Cardinalities, expected number of
elements, read/write ratios, expected response times, etc. etc.

In my opinion, the same is true for generating queries. That works in
theory, but in practice, every vendor has its own optimization techniques.
Taking SQL as an example, there might even be keywords that are supported
by one vendor, but not by another. There might be (materialized) views in
the schema that have quicker access to certain things than direct table
access. There might be a connected search backend (e.g. ElasticSearch) that
can handle certain lookups much quicker than the main database system. Even
if TinkerPop creates a basic SQL statement, that would get the job done,
vendors will surely not be willing to deal with pre-generated SQL
statements (or CQL or Cypher or ...). It would be much easier for them to
analyze the raw bytecode and generate statements from there.

Bottom line: the sql() bytecode instruction is a good thing (though, I
would call it script() to make it independent from the underlying
database), but TinkerPop shouldn't attempt to use it / build queries for
the underlying database. Leave that up to the providers.

Cheers,
Daniel



On Tue, May 7, 2019 at 11:04 AM Marko Rodriguez 
wrote:

> Here is a thought…
>
> Think about what this means for Apache Cassandra. Users will be able to
> define a graphdb-based n-tuple schema that has #fields denoting global
> indices, vertex-centric indices, full-text search indices, denormalized
> data, etc. … It will be possible for Apache TinkerPop to take the user's
> n-tuple schema and then CREATE TABLEs accordingly in Cassandra and thus,
> optimized for the user’s graph data and queries. In other words,
> theoretically, we should be able to create an optimially index’d Cassandra
> keyspace for a user’s specific n-tuple data. In other words, TP4 creates
> Titans! And best of all, there is no “Titan” middle layer. We just talk
> directly to Cassandra. Cassandra gives us tuples and resolves pointers.
>
> Now hold on to your undergarments.
>
> A user can state that they plan to have numerous concurrent users
> interacting with the database.
> - Connect RxJavaSerialProcessor.
> A user can state that they plan to do batch analytics weekly.
> - Connect SparkProcessor.
> A user can state that their queries tend to jump around the graph.
> - Connect AkkaProcessor.
> …
>
> Given a questionnaire and a user’s graphdb-based n-tuple schema, we could
> provide a service that does:
>
> Processing your questionnaire answers and n-tuple schema.
>
> Using Apache Cassandra as the underlying structure.
> Generating CQL script:
> ...for creating appropriate indices.
> ...for denormalizing row data in order to limit pointer
> chasing.
> Using PipesProcessor as the primary real-time processor.
> Using SparkProcessor as the primary batch processor.
> Exposing Gremlin as a graph query language.
> Exposing Cypher as a graph query language.
> Configuring TP4VM MachineServer for 127.0.0.1:8080.
>
> Your database is ready for download:
>
> http://tinkerpop.apache.org/db-generator/GraphDB+Cassandra+Pipes+Spark+Gremlin+Cypher.zip
> <
> http://tinkerpop.apache.org/db-generator/GraphDB+Cassandra+Pipes+Spark+Gremlin+Cypher.zip
> >
>
> Its wild, but its not crazy. From what I can see, it is theoretically
> possible to provide a service of this nature with TP4.
>
> Marko.
>
> http://rredux.com 
>
>
>
>
> > On May 7, 2019, at 11:14 AM, Marko Rodriguez 
> wrote:
> >
> > When your hot, your hot. Going to keep pushin’.
> >
> > What is the difference between a relational database's and a graph
> database’s encoding of a property graph? The short answer, NOTHING. The
> n-tuple model for a subset of the TinkerPop toy graph is:
> >
> > {#type:vertex, #id:1, #label:person, name:marko, age:29,
> #outE:*{#outV=*{#id=1}}}
> > {#type:vertex, #id:4, #label:person, name:josh, age:32}
> > {#type:vertex, #id:2, #label:person, name:vadas, age:27}
> > {#type:edge, #id:7, #label:knows, #outV:*{#id=1}, #inV:*{#id=2}}
> > {#type:edge, #id:8, #label:knows, #outV:*{#id=1}, #inV:*{#id=4}}
> >
> > MySQL and Neo4j would talk with TP4 via the same above tuples. What
> makes MySQL different from Neo4j is how the pointers are resolved.
> >
> > First, lets talk about the MySQL schema that ultimately holds the
> graphdb instance data.
> >
> > CREATE TABLE #V {
> >   #id int NOT NULL PRIMARY KEY,
> >   #label varchar,
> >   name varchar,
> >   age int,
> >   #outE varchar
> > }
> >
> > CREATE TABLE #E {
> >   #id int NOT NULL PRIMARY KEY,
> >   #label varchar,
> >   #outV int,
> >   #inV int,
> >   FOREIGN KEY (#outV) REFERENCES V(#id),
> >   FOREIGN KEY (#inV) REFERENCES V(#id)

[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2209:
---

This is a known issue: https://issues.apache.org/jira/browse/TINKERPOP-1048

Unfortunately, I don't think we can change that. TinkerPop itself ignores 
numeric data types (meaning, an Integer 1 is considered equal to a Long 1). But 
when it comes to the graph step, it's really up to the provider, e.g. how he 
decides to translate the provided input variables to a backend query.

I'm not entirely sure about it, but my guess is, that there are 2 different 
code paths in {{JanusGraphStep}} / {{JanusGraphStepStrategy}} - one of them 
converts the Integers, the other doesn't.

> hasId is not converting properly when multiple values are passed
> 
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow 
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
>  I found that hasId is performing `~id.eq` against arrays instead of 
> `~id.within` For a workaround the user reporting the issue found that quoting 
> the values or converting them to longs worked. 
>  
> ```
> {{ids = [8440,12536]}}
> {{paths = 
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths = 
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```



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

[jira] [Commented] (TINKERPOP-2209) hasId is not converting properly when multiple values are passed

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2209:
---

This is the expected behavior. {{hasId}} accepts varargs; a collection is a 
single argument, thus it will be translated into {{eq()}}. However, if you pass 
an array, it will be translated into {{within}}.
  
{code:java}
gremlin> ids = [8440,12536]
==>8440
==>12536
gremlin> 
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100]
==>[GraphStep(vertex,[8440, 12536]), RepeatStep(until([HasStep([~id.eq([8440, 
12536])])]),[VertexStep(O
gremlin> ids = [8440,12536].toArray()
==>8440
==>12536
gremlin> 
g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().toString()[0..<100]
==>[GraphStep(vertex,[8440, 12536]), 
RepeatStep(until([HasStep([~id.within([8440, 12536])])]),[VertexSt
{code}
{{g.V(ids)}} returns all vertices, because {{GraphStep}} is the only step that 
unfolds collections internally. {{g.V().hasId(ids)}} returns all vertices, 
because in this case, {{hasId}} gets folded into {{GraphStep}}. Theoretically, 
we could remove the automatic unfolding in {{GraphStep}}, but practically, this 
would be a major breaking change. Likewise, we can't do the automatic unfolding 
for every other step, as you wouldn't be able to actually test for equal 
collections anymore.

> hasId is not converting properly when multiple values are passed
> 
>
> Key: TINKERPOP-2209
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2209
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.3
> Environment: loaded GraphOfTheGods in JanusGraph 0.3.1 on a macbook.
>Reporter: Chris Hupman
>Priority: Minor
>
> While [trying to answer a question on Stack Overflow 
> |[https://stackoverflow.com/questions/55912624/get-all-edges-between-multiple-vertices-janusgraph/55929179#55929179]]
>  I found that hasId is performing `~id.eq` against arrays instead of 
> `~id.within` For a workaround the user reporting the issue found that quoting 
> the values or converting them to longs worked. 
>  
> ```
> {{ids = [8440,12536]}}
> {{paths = 
> g.V(ids).until(hasId(ids)).repeat(out().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.eq([4112, 4128, ...])])]),}}{{}}
> {{paths = 
> g.V(ids).until(hasId("8440","12536")).repeat(outE().simplePath()).limit(10).path().explain()}}
> {{...RepeatStep(until([HasStep([~id.within([8440, 12536])])])}}
> ```



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

[jira] [Commented] (TINKERPOP-2187) Two issues with the ShortestPathVertexProgram

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2187:
---

Also, see the JavaDoc for {{MessageCombiner}}:

{quote}
 * A MessageCombiner allows two messages in route to the same vertex to be 
aggregated into a single message.
 * Message combining can reduce the number of messages sent between vertices 
and thus, reduce network traffic.
 * Not all messages can be combined and thus, this is an optional feature of a 
VertexProgram.
{quote}

In other words, a {{GraphComputer}} should work in any case, whether the 
message combiner is provided or not.

> Two issues with the ShortestPathVertexProgram
> -
>
> Key: TINKERPOP-2187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2187
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> While trying to update JanusGraph to TinkerPop 3.4.0, I encountered two 
> issues with the {{ShortestPathVertexProgramm}}:
>  # {{ShortestPathVertexProgram.getMessageScopes()}} returns an empty 
> collection which doesn't work for a graph computer that uses these scopes to 
> execute the edge traversal. I think the scopes should be {{Global}} and 
> {{Local}} with the edge traversal.
>  # The {{ShortestPathVertexProgram}} defines no message combiner, but 
> {{sendMessages()}} can apparently still send multiple messages for the same 
> vertex.
>  For some reason, this doesn't lead to any problems for the 
> {{TinkerGraphComputer}}. (Maybe it receives each message before another one 
> can be sent for the same vertex?)
>  For {{FulgoraGraphComputer}} however some tests result in a situation where 
> multiple messages are sent to the same vertex which fails because no combiner 
> is defined.
>  So, I'd say that the {{ShortestPathVertexProgram}} should have a message 
> combiner.



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

[jira] [Commented] (TINKERPOP-2187) Two issues with the ShortestPathVertexProgram

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2187:
---

The message scope should be {{Global}} only, SPVP never sends local messages.

Logically, a message combiner doesn't make much sense IMO. There's nothing to 
combine to reduce the message size, all I could do is turn messages into Lists 
of Triplets. However, that means messages would become larger (perhaps too 
large in certain scenarios). I'm wondering if there's something wrong in 
FulgoraGraphComputer; it really should just process every incoming message.

> Two issues with the ShortestPathVertexProgram
> -
>
> Key: TINKERPOP-2187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2187
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> While trying to update JanusGraph to TinkerPop 3.4.0, I encountered two 
> issues with the {{ShortestPathVertexProgramm}}:
>  # {{ShortestPathVertexProgram.getMessageScopes()}} returns an empty 
> collection which doesn't work for a graph computer that uses these scopes to 
> execute the edge traversal. I think the scopes should be {{Global}} and 
> {{Local}} with the edge traversal.
>  # The {{ShortestPathVertexProgram}} defines no message combiner, but 
> {{sendMessages()}} can apparently still send multiple messages for the same 
> vertex.
>  For some reason, this doesn't lead to any problems for the 
> {{TinkerGraphComputer}}. (Maybe it receives each message before another one 
> can be sent for the same vertex?)
>  For {{FulgoraGraphComputer}} however some tests result in a situation where 
> multiple messages are sent to the same vertex which fails because no combiner 
> is defined.
>  So, I'd say that the {{ShortestPathVertexProgram}} should have a message 
> combiner.



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

[jira] [Assigned] (TINKERPOP-2187) Two issues with the ShortestPathVertexProgram

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz reassigned TINKERPOP-2187:
-

Assignee: Daniel Kuppitz

> Two issues with the ShortestPathVertexProgram
> -
>
> Key: TINKERPOP-2187
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2187
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>Reporter: Florian Hockmann
>    Assignee: Daniel Kuppitz
>Priority: Minor
>
> While trying to update JanusGraph to TinkerPop 3.4.0, I encountered two 
> issues with the {{ShortestPathVertexProgramm}}:
>  # {{ShortestPathVertexProgram.getMessageScopes()}} returns an empty 
> collection which doesn't work for a graph computer that uses these scopes to 
> execute the edge traversal. I think the scopes should be {{Global}} and 
> {{Local}} with the edge traversal.
>  # The {{ShortestPathVertexProgram}} defines no message combiner, but 
> {{sendMessages()}} can apparently still send multiple messages for the same 
> vertex.
>  For some reason, this doesn't lead to any problems for the 
> {{TinkerGraphComputer}}. (Maybe it receives each message before another one 
> can be sent for the same vertex?)
>  For {{FulgoraGraphComputer}} however some tests result in a situation where 
> multiple messages are sent to the same vertex which fails because no combiner 
> is defined.
>  So, I'd say that the {{ShortestPathVertexProgram}} should have a message 
> combiner.



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

[jira] [Created] (TINKERPOP-2207) Provide SimpleValueMapStrategy

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2207:
-

 Summary: Provide SimpleValueMapStrategy
 Key: TINKERPOP-2207
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2207
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.4.1
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


Implement a {{SimpleValueMapStrategy}} that can be used by providers who do not 
support multi-valued properties. The strategy should automatically unfold 
{{valueMap()}}'s values and thus turn them into single values.



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

Re: The Fundamental Structure Instructions Already Exist! (w/ RDBMS Example)

[Daniel Kuppitz]

>
> we don’t support ‘null' in TP


I don't think it's a good idea to keep this mindset for TP4; NULLs are too
important in RDBMS. I don't know, maybe you can convince SQL people that
dropping a value is the same as setting its value to NULL. It would work
for you and me and everybody else who's familiar with Gremlin, but SQL
people really love their NULLs

TSymbol: like Ruby, I think we need “enum-like” symbols (e.g., #id, #label).


I'd prefer to just have special accessors for these. E.g. g.V().meta("id").
At least valueMaps would then only have String-keys.
I see the issue with that (naming collisions), but it's still better than
the enums in my opinion (which became a pain when started to implement
GLVs).

Also, what I'm wondering about now: Have you thought about Stored
Procedures and Views in RDBMS? Views can be treated as tables, easy, but
what about stored procedures? SPs can be found in many more DBMS, would be
bad to not support them (or hack something ugly together later in the
development process).

Cheers,
Daniel


On Mon, Apr 29, 2019 at 7:34 AM Marko Rodriguez 
wrote:

> Hi,
>
> *** This email is primarily for Josh (and Kuppitz). However, if others are
> interested… ***
>
> So I did a lot of thinking this weekend about structure/ and this morning,
> I prototyped both graph/ and rdbms/.
>
> This is the way I’m currently thinking of things:
>
> 1. There are 4 base types in structure/.
> - Primitive: string, long, float, int, … (will constrain
> these at some point).
> - TTuple: key/value map.
> - TSequence: an iterable of v objects.
> - TSymbol: like Ruby, I think we need “enum-like” symbols
> (e.g., #id, #label).
>
> 2. Every structure has a “root.”
> - for graph its TGraph implements TSequence
> - for rdbms its a TDatabase implements
> TTuple
>
> 3. Roots implement Structure and thus, are what is generated by
> StructureFactory.mint().
> - defined using withStructure().
> - For graph, its accessible via V().
> - For rdbms, its accessible via db().
>
> 4. There is a list of core instructions for dealing with these
> base objects.
> - value(K key): gets the TTuple value for the provided key.
> - values(K key): gets an iterator of the value for the
> provided key.
> - entries(): gets an iterator of T2Tuple objects for the
> incoming TTuple.
> - hasXXX(A,B): various has()-based filters for looking
> into a TTuple and a TSequence
> - db()/V()/etc.: jump to the “root” of the withStructure()
> structure.
> - drop()/add(): behave as one would expect and thus.
>
> 
>
> For RDBMS, we have three interfaces in rdbms/.
> (machine/machine-core/structure/rdbms)
>
> 1. TDatabase implements TTuple // the root
> structure that indexes the tables.
> 2. TTable implements TSequence> // a table is a sequence
> of rows
> 3. TRow implements TTuple> // a row has string column
> names
>
> I then created a new project at machine/structure/jdbc). The classes in
> here implement the above rdbms/ interfaces/
>
> Here is an RDBMS session:
>
> final Machine machine = LocalMachine.open();
> final TraversalSource jdbc =
> Gremlin.traversal(machine).
> withProcessor(PipesProcessor.class).
> withStructure(JDBCStructure.class,
> Map.of(JDBCStructure.JDBC_CONNECTION, "jdbc:h2:/tmp/test"));
>
> System.out.println(jdbc.db().toList());
> System.out.println(jdbc.db().entries().toList());
> System.out.println(jdbc.db().value("people").toList());
> System.out.println(jdbc.db().values("people").toList());
> System.out.println(jdbc.db().values("people").value("name").toList());
> System.out.println(jdbc.db().values("people").entries().toList());
>
> This yields:
>
> []
> [PEOPLE:]
> []
> [, ]
> [marko, josh]
> [NAME:marko, AGE:29, NAME:josh, AGE:32]
>
> The bytecode of the last query is:
>
> [db(), values(people),
> entries]
>
> JDBCDatabase implements TDatabase, Structure.
> *** JDBCDatabase is the root structure and is referenced by db()
> *** (CRUCIAL POINT)
>
> Assume another table called ADDRESSES with two columns: name and city.
>
>
> jdbc.db().values(“people”).as(“x”).db().values(“addresses”).has(“name”,eq(path(“x”).by(“name”))).value(“city”)
>
> The above is equivalent to:
>
> SELECT city FROM people,addresses WHERE people.name=addresses.name
>
> If you want to do an inner join (a product), you do this:
>
>
> jdbc.db().values(“people”).as(“x”).db().values(“addresses”).has(“name”,eq(path(“x”).by(“name”))).as(“y”).path(“x”,”y")
>
> The above is equivalent to:
>
> SELECT * FROM addresses INNER JOIN people ON people.name=addresses.name
>
> NOTES:
> 1. Instead of select(), we simply jump to the root via db() (or
> V() for graph).
> 2. Instead of project(),

[jira] [Closed] (TINKERPOP-2191) Implement EdgeLabelVerificationStrategy

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2191.
-
   Resolution: Fixed
Fix Version/s: 3.4.2
   3.3.7

> Implement EdgeLabelVerificationStrategy
> ---
>
> Key: TINKERPOP-2191
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2191
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.6, 3.4.1
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.7, 3.4.2
>
>
> Using edge-steps, without specifying any labels, is documented as an 
> anti-pattern. We should have a strategy that verifies that all edge-steps 
> specify at least one label.
> The strategy should not be added by default, as not every provider may agree 
> that this an anti-pattern. It should also be possible to choose how the 
> strategy behaves, e.g. whether it throws an exception or only logs a warning 
> message.



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

Re: Using a bot to keep dependencies up to date

[Daniel Kuppitz]

Pretty cool, I like that (if only Travis would be a little more reliable).

Cheers,
Daniel


On Wed, Apr 3, 2019 at 9:43 AM Florian Hockmann 
wrote:

> Hi,
>
> we have a lot of dependencies in TinkerPop in different projects and
> even across different languages. That makes it hard to keep them updated
> which sometimes has security implications.
>
> I recently noticed that other open source projects use a bot that
> regularly checks whether any updates are available for their
> dependencies and then creates one PR per dependency. Just to try it out
> with TinkerPop, I activated such a bot on my fork:
>
> https://github.com/florianhockmann/tinkerpop/pulls
>
> and the overall result looks quite good in my opinion. It created a lot
> of PRs* and most could probably be directly merged. The bot can also be
> easily configured just by adding comments to its PR, for example to
> ignore a certain (major/minor/patch) version of a dependency:
>
> https://github.com/FlorianHockmann/tinkerpop/pull/24#issuecomment-473936360
>
> What do you think about adding such a bot for our repo?
>
>
> * This is limited to only 5 PRs per day at first to not overwhelm a
> project with PRs.
>
>
>

[jira] [Updated] (TINKERPOP-2191) Implement EdgeLabelVerificationStrategy

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2191:
--
Summary: Implement EdgeLabelVerificationStrategy  (was: Implement 
LabelVerificationStrategy)

> Implement EdgeLabelVerificationStrategy
> ---
>
> Key: TINKERPOP-2191
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2191
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.6, 3.4.1
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
>
> Using edge-steps, without specifying any labels, is documented as an 
> anti-pattern. We should have a strategy that verifies that all edge-steps 
> specify at least one label.
> The strategy should not be added by default, as not every provider may agree 
> that this an anti-pattern. It should also be possible to choose how the 
> strategy behaves, e.g. whether it throws an exception or only logs a warning 
> message.



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

[jira] [Created] (TINKERPOP-2191) Implement LabelVerificationStrategy

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2191:
-

 Summary: Implement LabelVerificationStrategy
 Key: TINKERPOP-2191
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2191
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.4.1, 3.3.6
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


Using edge-steps, without specifying any labels, is documented as an 
anti-pattern. We should have a strategy that verifies that all edge-steps 
specify at least one label.

The strategy should not be added by default, as not every provider may agree 
that this an anti-pattern. It should also be possible to choose how the 
strategy behaves, e.g. whether it throws an exception or only logs a warning 
message.



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

Re: [VOTE] TinkerPop 3.4.1 Release

[Daniel Kuppitz]

>
> how did you notice it missing?


Well, I was actually reading through the SPARQL section, cause I never
really looked into it before. Then the last paragraph just looked a bit odd
w/o a code block.
If this would have been an old section, I would for sure have just skimmed
over it w/o recognizing the missing piece.

Cheers,
Daniel


On Wed, Mar 20, 2019 at 10:18 AM Robert Dale  wrote:

> Daniel, how did you notice it missing?  I didn't see the typical grey
> block.
>
> Robert Dale
>
>
> On Wed, Mar 20, 2019 at 11:01 AM Florian Hockmann 
> wrote:
>
> > Skimmed over the docs and didn't find any problems (apart from the
> already
> > mentioned missing SPARQL section).
> >
> > VOTE +1
> >
> > -Ursprüngliche Nachricht-
> > Von: Stephen Mallette 
> > Gesendet: Dienstag, 19. März 2019 21:31
> > An: dev@tinkerpop.apache.org
> > Betreff: Re: [VOTE] TinkerPop 3.4.1 Release
> >
> > >
> > > I skimmed through the user docs. They look good, however, the final
> > > code snippet at the bottom of
> > > http://tinkerpop.apache.org/docs/3.4.1/reference/#sparql-with-gremlin
> > > is missing (not too big of a deal IMO though).
> >
> >
> > hmm - i guess i can patch that in the docs post release, but why did that
> > happen
> >
> >
> > On Tue, Mar 19, 2019 at 4:28 PM Daniel Kuppitz  wrote:
> >
> > > *$ bin/validate-distribution.sh 3.4.1*
> > >
> > > Validating binary distributions
> > > * downloading Apache TinkerPop Gremlin
> > > (apache-tinkerpop-gremlin-console-3.4.1-bin.zip)...
> > > OK
> > > * validating signatures and checksums ...
> > >   * PGP signature ... OK
> > >   * SHA512 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.4.1-bin.zip)...
> > > OK
> > > * validating signatures and checksums ...
> > >   * PGP signature ... OK
> > >   * SHA512 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.4.1
> > > (apache-tinkerpop-3.4.1-src.zip)... OK
> > > * validating signatures and checksums ...
> > >   * PGP signature ... OK
> > >   * SHA512 checksum ... OK
> > > * unzipping Apache TinkerPop 3.4.1 ... OK
> > > * checking source files ... OK
> > > * building project ... OK
> > >
> > >
> > > I skimmed through the user docs. They look good, however, the final
> > > code snippet at the bottom of
> > > http://tinkerpop.apache.org/docs/3.4.1/reference/#sparql-with-gremlin
> > > is missing (not too big of a deal IMO though).
> > >
> > > VOTE +1
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > On Tue, Mar 19, 2019 at 11:59 AM Stephen Mallette
> > > 
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > We are happy to announce that TinkerPop 3.4.1 is ready for release.
> > > >
> > > > The release artifacts can be found at this location:
> > > > https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.1/
> > > >
> > > > The source distribution is provided by:
> > > > apache-tinkerpop-3.4.1-src.zip
> > > >
> > > > Two binary distributions are provided for user convenience:
> > > > apache-tinkerpop-gremlin-console-3.4.1-bin.zip
> > > > apache-tinkerpop-gremlin-server-3.4.1-bin.zip
> > > >
> >

Re: [VOTE] TinkerPop 3.4.1 Release

[Daniel Kuppitz]

*$ bin/validate-distribution.sh 3.4.1*

Validating binary distributions
* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.4.1-bin.zip)...
OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.1-bin.zip)...
OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.1 (apache-tinkerpop-3.4.1-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.4.1 ... OK
* checking source files ... OK
* building project ... OK


I skimmed through the user docs. They look good, however, the final code
snippet at the bottom of
http://tinkerpop.apache.org/docs/3.4.1/reference/#sparql-with-gremlin is
missing (not too big of a deal IMO though).

VOTE +1

Cheers,
Daniel


On Tue, Mar 19, 2019 at 11:59 AM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.4.1 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.1/
>
> The source distribution is provided by:
> apache-tinkerpop-3.4.1-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.4.1-bin.zip
> apache-tinkerpop-gremlin-server-3.4.1-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.4.1/ (user docs)
> http://tinkerpop.apache.org/docs/3.4.1/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.4.1/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.4.1/full/ (full javadoc)
> http://tinkerpop.apache.org/dotnetdocs/3.4.1/ (.NET API docs)
> http://tinkerpop.apache.org/jsdocs/3.4.1/ (Javascript API docs)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.4.1
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.4.1/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Friday (March 22,
> 2019) at 3pm EST.
>
> My vote is +1.
>
> NOTE: I had to push a commit to master after the tag for
> validate-distribution.sh. please pull that change if you need to run that
> script for purpose of review/testing.
>
> Thank you very much,
>
> Stephen
>

Re: Thoughts on is(), where(), select(), and path() for TP4.

[Daniel Kuppitz]

>
> 1. select() for getting value from incoming Map.
> 2. path() for getting an object from a Path history.


Great, I like that.

   3. … I don’t know if we will have global side-effects in TP4.


Hm, I don't know why you have any doubts about that. I think global
side-effects will be necessary and the functionality around them should be
extended (e.g. we need the clear() step to reset aggregations).

g.V().values(“name”)
> g.V().select(“name”)


Cool, let's get rid of values().

Cheers,
Daniel



On Mon, Mar 18, 2019 at 7:29 AM Marko Rodriguez 
wrote:

> Hi,
>
> In TP4, Bytecode instruction arguments can be Bytecode. Well of course,
> this is like in TP3 --- nested traversals (union(), repeat(), etc.).
> However! — Bytecode can also be used for singleton arguments. For instance:
>
> has(“name”,select(“a”).value(“name”))
> is(gt(select(“a”).out().count()))
>
> Thus, what were “constant” arguments in TP3 can now be “dynamic”
> (traversal-determined) arguments.
>
> Because arguments can be traversals, various steps are starting to blend
> into each other:
>
> is(gt(select(“a”))) <=> where(gt(“a”))
>
> Now, we can keep where() in Gremlin, but at the bytecode level, it can
> just translate to an is() instruction. However, perhaps we can remove one
> from the Gremlin language…?
>
> Another thing that I want to clean up in Gremlin4 is select(). We have
> overloaded this step to the extreme where it can:
>
> 1. select a value from the incoming Map.
> 2. select an object from the Path history.
> 3. select a sideEffect from global side-effects.
>
> I think we should split it up:
>
> 1. select() for getting value from incoming Map.
> 2. path() for getting an object from a Path history.
> 3. … I don’t know if we will have global side-effects in TP4.
>
> Thus,
>
> g.V().as(“a”).out().as(“b”).select(“a”,”b”).by(“name”)
>
> would become…
>
> g.V().as(“a”).out().as(“b’).path(“a”,”b”).by(“name”)
>
> Next, if we assume that Vertex and Edge are “MapLike”, then what is the
> difference between values() and select()?
>
> g.V().values(“name”)
> g.V().select(“name”)
>
> Any thoughts on the future of is(), where(), select(), and path() would be
> appreciated.
>
> Thanks,
> Marko.
>
> http://markorodriguez.com
>
>
>
>

Re: [VOTE] TinkerPop 3.3.6 Release

[Daniel Kuppitz]

Dah, nevermind, it just worked. I ran an apt update before I checked the
versions, so I was probably using an old one yesterday.

All good.

VOTE +1

Cheers,
Daniel


On Tue, Mar 19, 2019 at 7:28 AM Daniel Kuppitz  wrote:

> I have 2 SDKs:
>
> $ dotnet --list-sdks
> 2.1.200 [/usr/share/dotnet/sdk]
> 2.2.105 [/usr/share/dotnet/sdk]
>
>
> The newest apparently being the active one:
>
> $ dotnet --version
> 2.2.105
>
>
> Cheers,
> Daniel
>
>
> On Tue, Mar 19, 2019 at 12:31 AM Florian Hockmann 
> wrote:
>
>> Which version of the .NET Core SDK do you have? It needs to be >= 2.1.300
>>
>> You can check with `dotnet --info`
>>
>> Am 19.03.2019 um 02:02 schrieb Daniel Kuppitz:
>> > Hm, validate-distribution.sh fails on my system. It's in .NET though, so
>> > chances are high that I'm just missing some components.
>> >
>> > * checking source files ... OK
>> > * building project ... failed
>> >
>> >   Restore completed in 42.08 ms for
>> >
>> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj.
>> > Microsoft (R) Build Engine version 15.7.177.53362 for .NET Core
>> > Copyright (C) Microsoft Corporation. All rights reserved.
>> >
>> >   Restore completed in 48.15 ms for
>> >
>> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj.
>> >   Restore completed in 48.16 ms for
>> >
>> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net.Template/Gremlin.Net.Template.csproj.
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning : The type initializer for 'LibGit2Sharp.Core.NativeMethods'
>> threw
>> > an exception.
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning :at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf)
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning :at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2
>> pathRetriever)
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning :at LibGit2Sharp.Repository.Discover(String startingPath)
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning :at
>> > Microsoft.Build.Tasks.Git.GitOperations.LocateRepository(String
>> directory)
>> > in /_/src/Microsoft.Build.Tasks.Git.Operations/GitOperations.cs:line 26
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning :at
>> >
>> Microsoft.Build.Tasks.Git.RepositoryTasks.LocateRepository(LocateRepository
>> > task) in
>> > /_/src/Microsoft.Build.Tasks.Git.Operations/RepositoryTasks.cs:line 58
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >
>> /home/daniel/.nuget/packages/microsoft.sourcelink.common/1.0.0-beta2-18618-05/build/Microsoft.SourceLink.Common.targets(53,5):
>> > warning : Source control information is not available - the generated
>> > source link is empty.
>> >
>> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
>> >   Gremlin.Net ->
>> >
>> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/bin/Release/netstandard2.0/Gremlin.Net.dll
>> >   Gremlin.Net.Template ->
>> >
>> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net.Template/bin/Release/netcoreapp2.0/Gremlin.Net.Template.dll
>> >
>> > Build succeeded.
>> >
>> >
>> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
>> > warning : The type initializer for 'Lib

Re: [VOTE] TinkerPop 3.3.6 Release

[Daniel Kuppitz]

I have 2 SDKs:

$ dotnet --list-sdks
2.1.200 [/usr/share/dotnet/sdk]
2.2.105 [/usr/share/dotnet/sdk]


The newest apparently being the active one:

$ dotnet --version
2.2.105


Cheers,
Daniel


On Tue, Mar 19, 2019 at 12:31 AM Florian Hockmann 
wrote:

> Which version of the .NET Core SDK do you have? It needs to be >= 2.1.300
>
> You can check with `dotnet --info`
>
> Am 19.03.2019 um 02:02 schrieb Daniel Kuppitz:
> > Hm, validate-distribution.sh fails on my system. It's in .NET though, so
> > chances are high that I'm just missing some components.
> >
> > * checking source files ... OK
> > * building project ... failed
> >
> >   Restore completed in 42.08 ms for
> >
> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj.
> > Microsoft (R) Build Engine version 15.7.177.53362 for .NET Core
> > Copyright (C) Microsoft Corporation. All rights reserved.
> >
> >   Restore completed in 48.15 ms for
> >
> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj.
> >   Restore completed in 48.16 ms for
> >
> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net.Template/Gremlin.Net.Template.csproj.
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning : The type initializer for 'LibGit2Sharp.Core.NativeMethods'
> threw
> > an exception.
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf)
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2 pathRetriever)
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :at LibGit2Sharp.Repository.Discover(String startingPath)
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :at
> > Microsoft.Build.Tasks.Git.GitOperations.LocateRepository(String
> directory)
> > in /_/src/Microsoft.Build.Tasks.Git.Operations/GitOperations.cs:line 26
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :at
> >
> Microsoft.Build.Tasks.Git.RepositoryTasks.LocateRepository(LocateRepository
> > task) in
> > /_/src/Microsoft.Build.Tasks.Git.Operations/RepositoryTasks.cs:line 58
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.sourcelink.common/1.0.0-beta2-18618-05/build/Microsoft.SourceLink.Common.targets(53,5):
> > warning : Source control information is not available - the generated
> > source link is empty.
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >   Gremlin.Net ->
> >
> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/bin/Release/netstandard2.0/Gremlin.Net.dll
> >   Gremlin.Net.Template ->
> >
> /tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net.Template/bin/Release/netcoreapp2.0/Gremlin.Net.Template.dll
> >
> > Build succeeded.
> >
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning : The type initializer for 'LibGit2Sharp.Core.NativeMethods'
> threw
> > an exception.
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf)
> >
> [/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
> >
> /home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
> > warning :

Re: [VOTE] TinkerPop 3.3.6 Release

[Daniel Kuppitz]

Hm, validate-distribution.sh fails on my system. It's in .NET though, so
chances are high that I'm just missing some components.

* checking source files ... OK
* building project ... failed

  Restore completed in 42.08 ms for
/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj.
Microsoft (R) Build Engine version 15.7.177.53362 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 48.15 ms for
/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj.
  Restore completed in 48.16 ms for
/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net.Template/Gremlin.Net.Template.csproj.
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning : The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw
an exception.
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf)
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2 pathRetriever)
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at LibGit2Sharp.Repository.Discover(String startingPath)
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at
Microsoft.Build.Tasks.Git.GitOperations.LocateRepository(String directory)
in /_/src/Microsoft.Build.Tasks.Git.Operations/GitOperations.cs:line 26
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at
Microsoft.Build.Tasks.Git.RepositoryTasks.LocateRepository(LocateRepository
task) in
/_/src/Microsoft.Build.Tasks.Git.Operations/RepositoryTasks.cs:line 58
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.sourcelink.common/1.0.0-beta2-18618-05/build/Microsoft.SourceLink.Common.targets(53,5):
warning : Source control information is not available - the generated
source link is empty.
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
  Gremlin.Net ->
/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/bin/Release/netstandard2.0/Gremlin.Net.dll
  Gremlin.Net.Template ->
/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net.Template/bin/Release/netcoreapp2.0/Gremlin.Net.Template.dll

Build succeeded.

/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning : The type initializer for 'LibGit2Sharp.Core.NativeMethods' threw
an exception.
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at LibGit2Sharp.Core.NativeMethods.git_buf_free(GitBuf buf)
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at LibGit2Sharp.Core.Proxy.ConvertPath(Func`2 pathRetriever)
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at LibGit2Sharp.Repository.Discover(String startingPath)
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at
Microsoft.Build.Tasks.Git.GitOperations.LocateRepository(String directory)
in /_/src/Microsoft.Build.Tasks.Git.Operations/GitOperations.cs:line 26
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.build.tasks.git/1.0.0-beta2-18618-05/build/Microsoft.Build.Tasks.Git.targets(20,5):
warning :at
Microsoft.Build.Tasks.Git.RepositoryTasks.LocateRepository(LocateRepository
task) in
/_/src/Microsoft.Build.Tasks.Git.Operations/RepositoryTasks.cs:line 58
[/tmp/tpdv/tinkerpop-3.3.6/gremlin-dotnet/src/Gremlin.Net/Gremlin.Net.csproj]
/home/daniel/.nuget/packages/microsoft.sourcelink.common/

[jira] [Commented] (TINKERPOP-2170) Compare.eq doesn't produce consistent results

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2170:
---

Are you saying that this worked before? We were aware of the rounding issues, 
but that's a limitation dictated by the JVM.

{noformat}
gremlin> 1f==1d
==>true
gremlin> 1.53f==1.53d
==>false
 {noformat}

> Compare.eq doesn't produce consistent results
> -
>
> Key: TINKERPOP-2170
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2170
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.4
>    Reporter: Daniel Choi
>Assignee: Daniel Kuppitz
>Priority: Major
>
> https://issues.apache.org/jira/browse/TINKERPOP-2056 introduced a change to 
> start using NumberHelper for comparisons.
>  
> This seems to have introduced an interesting side effect:
> {code:java}
> Assert.assertTrue(Compare.eq.test(new Double(1.53), new Float(1.53)));
> {code}
> now fails in 3.3.4+ versions.  Interestingly, 
> {code:java}
> Assert.assertTrue(Compare.eq.test(new Double(1.5), new Float(1.5)));
> {code}
> works fine.  It seems the problem is coming from the fact that the 
> NumberHelper.DOUBLE_NUMBER_HELPER is chosen for the comparison of float and 
> double numbers, where
> {code:java}
> new Float(1.53).doubleValue();
>  => 1.529713897705
> new Double(1.53).doubleValue();
>  => 1.53{code}
> Not sure what the correct implementation here would be, but nonetheless this 
> seems to be a backwards incompatible change.
>  
>  



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

[jira] [Created] (TINKERPOP-2159) EventStrategy doesn't handle multi-valued properties

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2159:
-

 Summary: EventStrategy doesn't handle multi-valued properties
 Key: TINKERPOP-2159
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2159
 Project: TinkerPop
  Issue Type: Bug
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


As shown 
[here|https://groups.google.com/d/msgid/gremlin-users/434c5397-c854-4856-ae4a-48146303ae5f%40googlegroups.com?utm_medium=email&utm_source=footer].



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

[jira] [Updated] (TINKERPOP-2157) SparkStarBarrierInterceptor injects (Byte) 0

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2157:
--
Summary: SparkStarBarrierInterceptor injects (Byte) 0  (was: 
SparkStarBarrierInterceptor injects (Bte) 0)

> SparkStarBarrierInterceptor injects (Byte) 0
> 
>
> Key: TINKERPOP-2157
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2157
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.4.1
>    Reporter: Daniel Kuppitz
>Assignee: stephen mallette
>Priority: Major
>
> There are 3 tests that occasionally fail in 
> {{SparkGraphComputerProcessIntegrateTest}}:
>  * {{g_V_name_min}}
>  * {{g_V_name_max}}
>  * {{g_V_age_min}}
> In all cases, failure is a result of a mysterious {{(Byte) 0}}. Apparently, 
> this zero gets injected by the {{SparkStarBarrierInterceptor}}. I came to 
> this conclusion because I wasn't able to reproduce any of the failures after 
> excluding this interceptor. However, the failures happen randomly*, so I 
> can't say with 100% certainty that the interceptor is the problem.
>  
> * on my system it never happened in the Docker builds, rarely in IntelliJ 
> debug sessions, but quite often when I just run the test suite in IntelliJ



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

[jira] [Created] (TINKERPOP-2157) SparkStarBarrierInterceptor injects (Bte) 0

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2157:
-

 Summary: SparkStarBarrierInterceptor injects (Bte) 0
 Key: TINKERPOP-2157
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2157
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.4.1
Reporter: Daniel Kuppitz
Assignee: stephen mallette


There are 3 tests that occasionally fail in 
{{SparkGraphComputerProcessIntegrateTest}}:
 * {{g_V_name_min}}
 * {{g_V_name_max}}
 * {{g_V_age_min}}

In all cases, failure is a result of a mysterious {{(Byte) 0}}. Apparently, 
this zero gets injected by the {{SparkStarBarrierInterceptor}}. I came to this 
conclusion because I wasn't able to reproduce any of the failures after 
excluding this interceptor. However, the failures happen randomly*, so I can't 
say with 100% certainty that the interceptor is the problem.

 

* on my system it never happened in the Docker builds, rarely in IntelliJ debug 
sessions, but quite often when I just run the test suite in IntelliJ



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

[jira] [Commented] (TINKERPOP-2151) Support for Vertex and Edge property deserialization in Python GLV

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2151:
---

We could add {{WithOptions.adjacentIds}} (wouldn't have any effect on vertices, 
but would add {{outVId}} and {{inVId}} on edges). 

> Support for Vertex and Edge property deserialization in Python GLV
> --
>
> Key: TINKERPOP-2151
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2151
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: python
>Affects Versions: 3.3.5
>Reporter: Matthew Stafford
>Priority: Minor
>
> It seems that the GraphSON serialization in the Python GLV differs from other 
> GLVs (I've checked JavaScript and assuming Java as well) in that it doesn't 
> deserialize Vertex and Edge properties. I've found a few discussions of this 
> (TINKERPOP-1474, TINKERPOP-1565) but it doesn't seem there was a clear 
> resolution to whether this was something that'd be addressed in the 3.3.x 
> series or if things would be left with a lack of parity across GLVs and a 
> different solution was approached in the 3.4.x series.
> As mentioned else where, using `valuesMap` isn't an ideal solution due to the 
> lack of `inV` and `outV` in the edges. Since this was never quite resolved, 
> does it make sense for me to go in and make the changes to the GraphSON 
> serializers?



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

[jira] [Closed] (TINKERPOP-1882) Apply range and limit steps as early as possible

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1882.
-
   Resolution: Fixed
Fix Version/s: 3.4.1
   3.3.6

> Apply range and limit steps as early as possible
> 
>
> Key: TINKERPOP-1882
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1882
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.7, 3.3.1
>Reporter: Florian Hockmann
>    Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> For a traversal like
> {{g.V(a).out().valueMap().limit(123)}}
> we can simply move the {{limit()}} to the left so we get:
> {{g.V(a).out().limit(123).valueMap()}}
> This avoids unnecessary database lookups.
> We should create a strategy that moves the {{limit}} and the {{range}} step 
> like this to _the left_  for all {{map}} steps.



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

Re: ATTN Committers/PMC Members: Bio Update

[Daniel Kuppitz]

I think my bio is still pretty accurate, no changes needed.

Cheers,
Daniel


On Fri, Feb 1, 2019, 1:29 PM Stephen Mallette  wrote:

> I was hoping that an email to the dev list would have dealt with most of
> this administrative issue, but I haven't seen any updates directly to git
> or in the form of replies as of yet. I will begin reaching out directly to
> folks next week.
>
> On Fri, Jan 25, 2019 at 8:44 AM Stephen Mallette 
> wrote:
>
> > To Committers/PMC Members,
> >
> > As an Apache TinkerPop committer and/or PMC member, your name is listed
> on
> > the TinkerPop home page in the Contributor List[1] with your "bio". If
> you
> > are active on the project, your "bio" reflects what you have been working
> > on and what you expect to be working on with respect to TinkerPop for
> > recent times (i.e. for the previous six months and the following six
> > months). If you are currently inactive on the project, your "bio"
> reflects
> > the full scope of all your contributions throughout your active
> periods.[2]
> >
> > Please take a moment to update your bio directly in Git[2] or, if you
> > would prefer, please reply to this email with your bio update and it will
> > be added for you. If no changes are required, please reply to this email
> to
> > confirm that this is the case. Feel free to email me directly if you
> like.
> >
> > I think most bios need a bit of a refresh. Jorge, you should definitely
> > add GraphBinary to yours. I think "Release Manager" might be a good one
> for
> > folks to add in given my recent work on the Downloads page. Thanks
> everyone!
> >
> > [1] http://tinkerpop.apache.org/#contributors
> > [2]
> >
> http://tinkerpop.apache.org/docs/current/dev/developer/#contributor-listing
> > [3]
> >
> https://github.com/apache/tinkerpop/blob/master/docs/site/home/index.html
> >
>

[jira] [Closed] (TINKERPOP-2126) toString() methods not thread-safe

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2126.
-
Resolution: Fixed

> toString() methods not thread-safe
> --
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.5
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
> internal map, which could concurrently be modified (most likely in OLAP 
> environments).



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

[jira] [Closed] (TINKERPOP-2125) Extend release validation script

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2125.
-
   Resolution: Fixed
Fix Version/s: 3.4.1
   3.3.6

> Extend release validation script
> 
>
> Key: TINKERPOP-2125
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2125
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: build-release
>Affects Versions: 3.3.4
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> Verify that the source distribution doesn't contain any binary files (except 
> a whitelist of images, icons, kryo files, etc.).



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

[jira] [Updated] (TINKERPOP-2142) Support named sacks

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2142:
--
Summary: Support named sacks  (was: Support names sacks)

> Support named sacks
> ---
>
> Key: TINKERPOP-2142
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2142
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>        Reporter: Daniel Kuppitz
>Priority: Major
>
> The queries required to solve the SO question: 
> https://stackoverflow.com/questions/54336647/gremlin-query-to-find-connecting-scheduled-flight-routes-filtered-dynamically-on
>  require so many state variables, that I really wish we'd have named sacks.
> We would just need to add {{sack(String name)}} and {{sack(String name, 
> BiFunction sackOperator)}}.



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

[jira] [Created] (TINKERPOP-2142) Support names sacks

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2142:
-

 Summary: Support names sacks
 Key: TINKERPOP-2142
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2142
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Reporter: Daniel Kuppitz


The queries required to solve the SO question: 
https://stackoverflow.com/questions/54336647/gremlin-query-to-find-connecting-scheduled-flight-routes-filtered-dynamically-on
 require so many state variables, that I really wish we'd have named sacks.

We would just need to add {{sack(String name)}} and {{sack(String name, 
BiFunction sackOperator)}}.



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

[jira] [Updated] (TINKERPOP-2126) toString() methods not thread-safe

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2126:
--
Summary: toString() methods not thread-safe  (was: TraverserSet's 
toString() is not thread-safe)

> toString() methods not thread-safe
> --
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
> internal map, which could concurrently be modified (most likely in OLAP 
> environments).



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

[jira] [Reopened] (TINKERPOP-2126) TraverserSet's toString() is not thread-safe

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz reopened TINKERPOP-2126:
---

Reopening as the same issue occurred in {{ObjectWritable}}'s {{toString()}} 
method.

> TraverserSet's toString() is not thread-safe
> 
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
> internal map, which could concurrently be modified (most likely in OLAP 
> environments).



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

[jira] [Closed] (TINKERPOP-2136) Inside lower bound inclusion (documentation)

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2136.
-
   Resolution: Fixed
Fix Version/s: 3.4.1
   3.3.6

> Inside lower bound inclusion (documentation)
> 
>
> Key: TINKERPOP-2136
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2136
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.5
>Reporter: Martijn Dwars
>    Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.3.6, 3.4.1
>
>
> On [http://tinkerpop.apache.org/docs/current/reference/#has-step] there is an 
> example:
> {code:java}
> g.V().has('age',inside(20,30)).values('age') // 1
> {code}
> with the comment:
> {code:java}
> Find all vertices whose ages are between 20 (inclusive) and 30 (exclusive).
> {code}
> But if I run this in the Gremlin Groovy shell I see:
> {code:java}
> gremlin> g.V().has('age', inside(10, 30)).toString()
> ==>[GraphStep(vertex,[]), HasStep([age.and(gt(10), lt(30))])]
> {code}
> which means the lower bound and upper bound are both exclusive. In 
> particular, the lower bound is exclusive, _not_ inclusive. Right?



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

[jira] [Commented] (TINKERPOP-2136) Inside lower bound inclusion (documentation)

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-2136:
---

I just go ahead and merge the changes into {{tp33}} and {{master}}. Not worth a 
PR as it's just a minor fix in the user docs.

> Inside lower bound inclusion (documentation)
> 
>
> Key: TINKERPOP-2136
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2136
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.5
>Reporter: Martijn Dwars
>Assignee: Daniel Kuppitz
>Priority: Minor
>
> On [http://tinkerpop.apache.org/docs/current/reference/#has-step] there is an 
> example:
> {code:java}
> g.V().has('age',inside(20,30)).values('age') // 1
> {code}
> with the comment:
> {code:java}
> Find all vertices whose ages are between 20 (inclusive) and 30 (exclusive).
> {code}
> But if I run this in the Gremlin Groovy shell I see:
> {code:java}
> gremlin> g.V().has('age', inside(10, 30)).toString()
> ==>[GraphStep(vertex,[]), HasStep([age.and(gt(10), lt(30))])]
> {code}
> which means the lower bound and upper bound are both exclusive. In 
> particular, the lower bound is exclusive, _not_ inclusive. Right?



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

[jira] [Closed] (TINKERPOP-2124) InlineFilterStrategy produces wrong result

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2124.
-
   Resolution: Fixed
Fix Version/s: 3.4.1
   3.3.6

> InlineFilterStrategy produces wrong result
> --
>
> Key: TINKERPOP-2124
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2124
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.4
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {noformat}
> gremlin> g.V().hasLabel("person").
>or(and(has("age",gt(20)),
>   has("age",lt(30))),
>   and(has("age",gt(35)),
>   has("age",lt(40.
>  explain()
> ==>Traversal Explanation
> =
> Original Traversal [GraphStep(vertex,[]), 
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
>   p([age.lt(40)])]])]])]
> ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
>   p([age.lt(40)])]])]])]
> CountStrategy[O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
>   p([age.lt(40)])]])]])]
> MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
>   p([age.lt(40)])]])]])]
> FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
> [HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
>   p([age.lt(40)])]])]])]
> InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), 
> HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
> TinkerGraphStepStrategy  [P]   
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35), 
> lt(40))])]
> ProfileStrategy  [F]   
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35), 
> lt(40))])]
> StandardVerificationStrategy [V]   
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35), 
> lt(40))])]
> Final Traversal
> [TinkerGraphStep(vertex,[~label.eq(person), age.or(gt(20), lt(30), gt(35), 
> lt(40))])]
> {noformat}



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

[jira] [Closed] (TINKERPOP-2126) TraverserSet's toString() is not thread-safe

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2126.
-
   Resolution: Fixed
Fix Version/s: 3.4.1
   3.3.6

> TraverserSet's toString() is not thread-safe
> 
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.6, 3.4.1
>
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
> internal map, which could concurrently be modified (most likely in OLAP 
> environments).



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

[jira] [Updated] (TINKERPOP-2126) TraverserSet's toString() is not thread-safe

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2126:
--
Summary: TraverserSet's toString() is not thread-safe  (was: TraverserSet's 
toString() is no thread-safe)

> TraverserSet's toString() is not thread-safe
> 
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
> internal map, which could concurrently be modified (most likely in OLAP 
> environments).



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

Re: Development branch cleanup

[Daniel Kuppitz]

Alright, updated list:

TINKERPOP-1849 -- [TINKERPOP-1849] Provide a way to fold() with an index
TINKERPOP-2018 -- [TINKERPOP-2018] Generate API docs for Gremlin.Net
TINKERPOP-2102 -- [TINKERPOP-2102] Deprecate static fields on
TraversalSource related to remoting
TINKERPOP-2121 -- [TINKERPOP-2121] Bump Jackson Databind 2.9.8



On Tue, Jan 8, 2019 at 8:54 AM Stephen Mallette 
wrote:

> hmm - don't delete:
>
> TINKERPOP-1564 -- [TINKERPOP-1564] Distributed OLTP Traversals and the
> Introduction of Partition Concept
>
> i closed that, but with the "Later" resolution. maybe your little script
> should be updated to exclude that option.
>
> On Tue, Jan 8, 2019 at 10:53 AM Daniel Kuppitz  wrote:
>
> > The following branches are scheduled for deletion:
> >
> > TINKERPOP-1564 -- [TINKERPOP-1564] Distributed OLTP Traversals and the
> > Introduction of Partition Concept
> > TINKERPOP-1849 -- [TINKERPOP-1849] Provide a way to fold() with an index
> > TINKERPOP-2018 -- [TINKERPOP-2018] Generate API docs for Gremlin.Net
> > TINKERPOP-2051 -- [TINKERPOP-2051] Uniqueness of property ids
> > TINKERPOP-2102 -- [TINKERPOP-2102] Deprecate static fields on
> > TraversalSource related to remoting
> > TINKERPOP-2121 -- [TINKERPOP-2121] Bump Jackson Databind 2.9.8
> >
> >
> > Looks like we had some good housekeeping after the previous release, this
> > list used to be much longer.
> >
> > If there are no objections, I will delete those branches by EOD 1/11.
> >
> > Cheers,
> > Daniel
> >
>

Development branch cleanup

[Daniel Kuppitz]

The following branches are scheduled for deletion:

TINKERPOP-1564 -- [TINKERPOP-1564] Distributed OLTP Traversals and the
Introduction of Partition Concept
TINKERPOP-1849 -- [TINKERPOP-1849] Provide a way to fold() with an index
TINKERPOP-2018 -- [TINKERPOP-2018] Generate API docs for Gremlin.Net
TINKERPOP-2051 -- [TINKERPOP-2051] Uniqueness of property ids
TINKERPOP-2102 -- [TINKERPOP-2102] Deprecate static fields on
TraversalSource related to remoting
TINKERPOP-2121 -- [TINKERPOP-2121] Bump Jackson Databind 2.9.8


Looks like we had some good housekeeping after the previous release, this
list used to be much longer.

If there are no objections, I will delete those branches by EOD 1/11.

Cheers,
Daniel

Re: [VOTE] TinkerPop 3.4.0 Release

[Daniel Kuppitz]

All validations passed ...

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.4.0-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.0-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.4.0 (apache-tinkerpop-3.4.0-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.4.0 ... OK
* building project ... OK


... and given that the issues found by Florian are indeed minor ones (the
empty Python tabs are caused by missing CSS definitions; I already CTR'd a
fix
)
...

VOTE +1

Cheers,
Daniel


On Sat, Jan 5, 2019 at 5:57 AM Florian Hockmann 
wrote:

> I skimmed over the docs and they look good. I really like the new
> structure and the added sections :-) I only noticed one small issue: The
> Python tabs are empty for the first two code listings in Basic Gremlin:
> http://tinkerpop.apache.org/docs/3.4.0/reference/#basic-gremlin
>
> No idea what's going on there as the code examples for Python are
> definitely in the AsciiDoc file.
>
> I also tried to validate the distribution. Everything worked until it
> builds the project and executes tests which unfortunately fails on my
> system, probably because a test assumes that the installed locale is
> en_US. I'm getting this failure with my de_DE locale:
>
> /java.text.ParseException: Unparseable date: "Jan 12, 1952"//
> //at
>
> org.apache.tinkerpop.gremlin.driver.ser.binary.GraphBinaryReaderWriterRoundTripTest.input(GraphBinaryReaderWriterRoundTripTest.java:156)/
>
> The german representation of this date would be 12.01.1952 and other
> locales will again have different formats. We should change this test to
> work independently of the locally installed locale, but we can do that
> any time after the release.
>
> These two issues are really minor and shouldn't stop the release in my
> opinion, so: VOTE +1
>
> Am 04.01.2019 um 23:33 schrieb Stephen Mallette:
> >  sorrythe template is just broken. I'll make a note to fix
> that.
> >
> > The tag in Apache Git can be found here:
> > https://github.com/apache/tinkerpop/tree/3.4.0
> >
> > The release notes are available here:
> >
> https://github.com/apache/tinkerpop/blob/3.4.0/CHANGELOG.asciidoc
> >
> >
> >
> > On Fri, Jan 4, 2019 at 4:52 PM Robert Dale  wrote:
> >
> >> Some links point to 3.3.4 instead of 3.4.0.
> >>
> >> Robert Dale
> >>
> >>
> >> On Fri, Jan 4, 2019 at 4:51 PM Stephen Mallette 
> >> wrote:
> >>
> >>> Hello,
> >>>
> >>> We are happy to announce that TinkerPop 3.4.0 is ready for release.
> >>>
> >>> The release artifacts can be found at this location:
> >>> https://dist.apache.org/repos/dist/dev/tinkerpop/3.4.0/
> >>>
> >>> The source distribution is provided by:
> >>> apache-tinkerpop-3.4.0-src.zip
> >>>
> >>> Two binary distributions are provided for user convenience:
> >>> apache-tinkerpop-gremlin-console-3.4.0-bin.zip
> >>> apache-tinkerpop-gremlin-server-3.4.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.4.0/ (user docs)
> >>> http://tinkerpop.apache.org/docs/3.4.0/upgrade/ (upgrade docs)
> >>> http://tinkerpop.apache.org/javadocs/3.4.0/core/ (core
> javadoc)
> >>> http://tinkerpop.apache.org/javadocs/3.4.0/full/ (full
> javadoc)
> >>>
> >>> The tag in Apache Git can be found here:
> >>> https://github.com/apache/tinkerpop/tree/3.3.4
> >>>
> >>> The release notes are available here:
> >>>
> >> https://github.com/apache/tinkerpop/blob/3.3.4/CHANGELOG.asciidoc
> >>> The [VOTE] will be open for the next 72 hours --- closing Monday
> (January
> >>> 7, 2019) at 5:00pm EST.
> >>>
> >>>

[jira] [Updated] (TINKERPOP-2126) TraverserSet's toString() is no thread-safe

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2126:
--
Issue Type: Bug  (was: Improvement)

> TraverserSet's toString() is no thread-safe
> ---
>
> Key: TINKERPOP-2126
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
>
> {{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
> internal map, which could concurrently be modified (most likely in OLAP 
> environments).



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

[jira] [Created] (TINKERPOP-2126) TraverserSet's toString() is no thread-safe

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2126:
-

 Summary: TraverserSet's toString() is no thread-safe
 Key: TINKERPOP-2126
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2126
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


{{TraverserSet::toString()}} is not thread-safe as it uses an iterator on the 
internal map, which could concurrently be modified (most likely in OLAP 
environments).



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

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

Much better.

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.3.5-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.5-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.5 (apache-tinkerpop-3.3.5-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.3.5 ... OK
* building project ... OK


VOTE +1

Cheers,
Daniel


On Fri, Jan 4, 2019 at 7:32 AM Stephen Mallette 
wrote:

> Ok - re-deployed the zips and everything. validate-distribution.sh passes.
> I'm still +1 on this as it never failed for me in the past. Please feel
> free to review/vote - thanks
>
> On Thu, Jan 3, 2019 at 4:34 PM Robert Dale  wrote:
>
> > Looks good to me.
> >
> > Robert Dale
> >
> >
> > On Thu, Jan 3, 2019 at 4:06 PM Daniel Kuppitz  wrote:
> >
> > > Yea, I already had them locally, I just didn't feel like changing that
> > part
> > > of the validation script. Since we don't touch the zip files after they
> > > were generated, I assume that signing still works as expected.
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > On Thu, Jan 3, 2019 at 2:03 PM Stephen Mallette 
> > > wrote:
> > >
> > > > btw, in case you want to test you need to do:
> > > >
> > > > $ mvn install -Papache-release -DcreateChecksum=true -DskipTests
> > > >
> > > > and you will see the zip with signatures in /target. if you don't
> have
> > > gpg
> > > > stuff setup you can at least check the zip by changng "install" to
> > > > "package".
> > > >
> > > > On Thu, Jan 3, 2019 at 3:14 PM Stephen Mallette <
> spmalle...@gmail.com>
> > > > wrote:
> > > >
> > > > > I think I figured out how to ignore those directories. Had to
> > override
> > > > the
> > > > > default apache parent pom source distribution process - it didn't
> > take
> > > > into
> > > > > account non-JVM file stuffs. I didn't see where it was easily
> > > accessible
> > > > to
> > > > > extend so I just overrode the whole thing. Just pushed a fix on
> tp33
> > > and
> > > > > master.
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/tinkerpop/commit/28b63228fe09c12787ee5c96159fe6b97a774284
> > > > >
> > > > > Can someone please confirm that all is good before I go through
> 3.3.5
> > > > > release again (for a third time )?
> > > > >
> > > > > On Thu, Jan 3, 2019 at 11:54 AM Daniel Kuppitz 
> > > wrote:
> > > > >
> > > > >> rm -rf gremlin-dotnet/src/{obj,_site}
> > > > >> rm -rf
> > > > >>
> > gremlin-javascript/src/main/javascript/gremlin-javascript/node_modules
> > > > >>
> > > > >> This helps to get a clean build, git clean seems to be the better
> > > choice
> > > > >> though.
> > > > >> However, I have no clue how we can control the contents of the src
> > zip
> > > > >> file, I don't even know which of then maven plugin creates it.
> > > > >>
> > > > >> Cheers,
> > > > >> Daniel
> > > > >>
> > > > &g

[jira] [Created] (TINKERPOP-2125) Extend release validation script

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2125:
-

 Summary: Extend release validation script
 Key: TINKERPOP-2125
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2125
 Project: TinkerPop
  Issue Type: Improvement
  Components: build-release
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


Verify that the source distribution doesn't contain any binary files (except a 
whitelist of images, icons, kryo files, etc.).



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

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

Yea, I already had them locally, I just didn't feel like changing that part
of the validation script. Since we don't touch the zip files after they
were generated, I assume that signing still works as expected.

Cheers,
Daniel


On Thu, Jan 3, 2019 at 2:03 PM Stephen Mallette 
wrote:

> btw, in case you want to test you need to do:
>
> $ mvn install -Papache-release -DcreateChecksum=true -DskipTests
>
> and you will see the zip with signatures in /target. if you don't have gpg
> stuff setup you can at least check the zip by changng "install" to
> "package".
>
> On Thu, Jan 3, 2019 at 3:14 PM Stephen Mallette 
> wrote:
>
> > I think I figured out how to ignore those directories. Had to override
> the
> > default apache parent pom source distribution process - it didn't take
> into
> > account non-JVM file stuffs. I didn't see where it was easily accessible
> to
> > extend so I just overrode the whole thing. Just pushed a fix on tp33 and
> > master.
> >
> >
> >
> https://github.com/apache/tinkerpop/commit/28b63228fe09c12787ee5c96159fe6b97a774284
> >
> > Can someone please confirm that all is good before I go through 3.3.5
> > release again (for a third time )?
> >
> > On Thu, Jan 3, 2019 at 11:54 AM Daniel Kuppitz  wrote:
> >
> >> rm -rf gremlin-dotnet/src/{obj,_site}
> >> rm -rf
> >> gremlin-javascript/src/main/javascript/gremlin-javascript/node_modules
> >>
> >> This helps to get a clean build, git clean seems to be the better choice
> >> though.
> >> However, I have no clue how we can control the contents of the src zip
> >> file, I don't even know which of then maven plugin creates it.
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >>
> >> On Thu, Jan 3, 2019 at 9:04 AM Robert Dale  wrote:
> >>
> >> > Maybe anything generated should be excluded:
> >> >
> >> > src/docfx
> >> > src/gremlin-dotnet-source.iml
> >> > src/Gremlin.Net/Driver/obj
> >> > src/Gremlin.Net.Template.3.3.4.nupkg
> >> > src/nuget-4.4.1.exe
> >> > src/obj
> >> > src/_site
> >> > .vscode
> >> >
> >> > or better yet, 'git clean -fdx' before building the src zip.  I
> haven't
> >> > looked at the src zip build process so I'm not sure if that's
> >> compatible.
> >> >
> >> > Robert Dale
> >> >
> >> >
> >> > On Thu, Jan 3, 2019 at 10:34 AM Daniel Kuppitz 
> wrote:
> >> >
> >> > > I just found this entry in my log:
> >> > >
> >> > >  [exec] [19-01-03 03:20:16.409]Error:System.AggregateException:
> >> One
> >> > or
> >> > > more errors occurred.
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/hlxtywvr.c9b
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/b2ia4mzc.9sx
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/1ujoqpgt.8fv
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/7wgceclr.f8o
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/6xipa4ui.3bf
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/dz43j9do.zik
> >> > > does not exist)
> >> > >
> >> > >
> >> >
> >>
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/32w60ckf.kxh
> >> > >

Re: [VOTE] TinkerPop 3.2.11 Release

[Daniel Kuppitz]

Skimmed over the docs, they look good, too.

VOTE +1

On Thu, Jan 3, 2019 at 5:07 AM Robert Dale  wrote:

> validate-distribution.sh 3.2.11 passes.
>
> VOTE +1
>
> Robert Dale
>
>
> On Wed, Jan 2, 2019 at 4:49 PM Stephen Mallette 
> wrote:
>
> > Hello,
> >
> > We are happy to announce that TinkerPop 3.2.11 is ready for release.
> >
> > The release artifacts can be found at this location:
> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.2.11/
> >
> > The source distribution is provided by:
> > apache-tinkerpop-3.2.11-src.zip
> >
> > Two binary distributions are provided for user convenience:
> > apache-tinkerpop-gremlin-console-3.2.11-bin.zip
> > apache-tinkerpop-gremlin-server-3.2.11-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.11/ (user docs)
> > http://tinkerpop.apache.org/docs/3.2.11/upgrade/ (upgrade docs)
> > http://tinkerpop.apache.org/javadocs/3.2.11/core/ (core javadoc)
> > http://tinkerpop.apache.org/javadocs/3.2.11/full/ (full javadoc)
> >
> > The tag in Apache Git can be found here:
> > https://github.com/apache/tinkerpop/tree/3.2.11
> >
> > The release notes are available here:
> >
> https://github.com/apache/tinkerpop/blob/3.2.11/CHANGELOG.asciidoc
> >
> > The [VOTE] will be open for the next 72 hours --- closing Saturday
> (January
> > 5, 2018) at 5pm EST.
> >
> > My vote is +1.
> >
> > Thank you very much,
> >
> > Stephen
> >
>

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

I modified my validation script so that it copies the files from my m2
directory instead of downloading them. I also commented out the checksum
check (it can only fail as it would compare my local zip files against
remote checksum files) and the docs check (I haven't built them locally).
With that said, here's the output:

*Validating binary distributions*

* downloading Apache TinkerPop Gremlin
(apache-tinkerpop-gremlin-console-3.3.5-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.5-bin.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 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.5 (apache-tinkerpop-3.3.5-src.zip)... OK
* validating signatures and checksums ...
  * PGP signature ... OK
  * SHA512 checksum ... OK
* unzipping Apache TinkerPop 3.3.5 ... OK
* building project ... OK



Lines in gray highlight the tests that actually weren't executed. So, looks
like we're good to go.

Cheers,
Daniel


On Thu, Jan 3, 2019 at 1:14 PM Stephen Mallette 
wrote:

> I think I figured out how to ignore those directories. Had to override the
> default apache parent pom source distribution process - it didn't take into
> account non-JVM file stuffs. I didn't see where it was easily accessible to
> extend so I just overrode the whole thing. Just pushed a fix on tp33 and
> master.
>
>
> https://github.com/apache/tinkerpop/commit/28b63228fe09c12787ee5c96159fe6b97a774284
>
> Can someone please confirm that all is good before I go through 3.3.5
> release again (for a third time )?
>
> On Thu, Jan 3, 2019 at 11:54 AM Daniel Kuppitz  wrote:
>
> > rm -rf gremlin-dotnet/src/{obj,_site}
> > rm -rf
> > gremlin-javascript/src/main/javascript/gremlin-javascript/node_modules
> >
> > This helps to get a clean build, git clean seems to be the better choice
> > though.
> > However, I have no clue how we can control the contents of the src zip
> > file, I don't even know which of then maven plugin creates it.
> >
> > Cheers,
> > Daniel
> >
> >
> >
> > On Thu, Jan 3, 2019 at 9:04 AM Robert Dale  wrote:
> >
> > > Maybe anything generated should be excluded:
> > >
> > > src/docfx
> > > src/gremlin-dotnet-source.iml
> > > src/Gremlin.Net/Driver/obj
> > > src/Gremlin.Net.Template.3.3.4.nupkg
> > > src/nuget-4.4.1.exe
> > > src/obj
> > > src/_site
> > > .vscode
> > >
> > > or better yet, 'git clean -fdx' before building the src zip.  I haven't
> > > looked at the src zip build process so I'm not sure if that's
> compatible.
> > >
> > > Robert Dale
> > >
> > >
> > > On Thu, Jan 3, 2019 at 10:34 AM Daniel Kuppitz 
> wrote:
> > >
> > > > I just found this entry in my log:
> > > >
> > > >  [exec] [19-01-03 03:20:16.409]Error:System.AggregateException:
> One
> > > or
> > > > more errors occurred.
> > > >
> > > >
> > >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/hlxtywvr.c9b
> > > > does not exist)
> > > >
> > > >
> > >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/b2ia4mzc.9sx
> > > > does not exist)
> > > >
> > > >
> > >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
> > > > does not exist)
> > > >
> > > >
> > >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8v

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

rm -rf gremlin-dotnet/src/{obj,_site}
rm -rf
gremlin-javascript/src/main/javascript/gremlin-javascript/node_modules

This helps to get a clean build, git clean seems to be the better choice
though.
However, I have no clue how we can control the contents of the src zip
file, I don't even know which of then maven plugin creates it.

Cheers,
Daniel



On Thu, Jan 3, 2019 at 9:04 AM Robert Dale  wrote:

> Maybe anything generated should be excluded:
>
> src/docfx
> src/gremlin-dotnet-source.iml
> src/Gremlin.Net/Driver/obj
> src/Gremlin.Net.Template.3.3.4.nupkg
> src/nuget-4.4.1.exe
> src/obj
> src/_site
> .vscode
>
> or better yet, 'git clean -fdx' before building the src zip.  I haven't
> looked at the src zip build process so I'm not sure if that's compatible.
>
> Robert Dale
>
>
> On Thu, Jan 3, 2019 at 10:34 AM Daniel Kuppitz  wrote:
>
> > I just found this entry in my log:
> >
> >  [exec] [19-01-03 03:20:16.409]Error:System.AggregateException: One
> or
> > more errors occurred.
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/hlxtywvr.c9b
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/b2ia4mzc.9sx
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/1ujoqpgt.8fv
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/7wgceclr.f8o
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/6xipa4ui.3bf
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/dz43j9do.zik
> > does not exist)
> >
> >
> (/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/32w60ckf.kxh
> > does not exist) ---> System.IO.FileNotFoundException:
> >
> >
> /home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/hlxtywvr.c9b
> > does not exist
> >
> > I guess the gremlin-dotnet/src/Gremlin.Net/Driver/obj/xdoc/cache
> directory
> > shouldn't be part of the zip (maybe not even
> > gremlin-dotnet/src/Gremlin.Net/Driver/obj).
> >
> >
> > On Thu, Jan 3, 2019 at 8:01 AM Daniel Kuppitz  wrote:
> >
> > > Confirmed, building the tag just worked for me, too.
> > >
> > >
> > > On Thu, Jan 3, 2019 at 7:59 AM Robert Dale  wrote:
> > >
> > >> Building the tag from github works fine.  Looks like some local build
> > >> artifacts snuck into the src.zip.
> > >>
> > >> Excluding gremlin-dotnet, validate-distribution passes.
> > >>
> > >> Robert Dale
> > >>
> > >>
> > >> On Thu, Jan 3, 2019 at 9:49 AM Robert Dale  wrote:
> > >>
> > >> > Daniel, I had to install 'msbuild' in addition to the mono packages.
> > I
> > >> > also installed mono-addins-devel. I don't know if that actually did
> > >> > anything.
> > >> >
> > >> > But now I get some errors with :
> > >> >
> > >> > System.IO.FileNotFoundException:
> > >>
> >
> */home/smallette*/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
> > >> > does not exist
> > >> >
> > >> >
> > >> > Robert Dale
> > >> >
> > >> >
> > >> > On Thu, Jan 3, 2019 at 9:43 AM Daniel Kuppitz 
> > wrote:
> > >> >
> > >> >> I skimmed over the docs, they look good to me, but the
> > >> >> validate-distribution.sh script fails the same way as for Robert.
> > >> >>
> > >> >> Investigating
> > >> >>
> > >> >> Cheers,
> > >> >> Daniel
> > >> >>
> > >> >>
> > >> >> On Wed, Jan 2, 2019 at 2:58 PM Stephen Mallette <
> > spmalle...@gmail.com>
> > >> >> wrote:
> > >> >>
> > >> >> > Hello,
> > >> >&

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

I just found this entry in my log:

 [exec] [19-01-03 03:20:16.409]Error:System.AggregateException: One or
more errors occurred.
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/hlxtywvr.c9b
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/b2ia4mzc.9sx
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/1ujoqpgt.8fv
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/7wgceclr.f8o
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/6xipa4ui.3bf
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/dz43j9do.zik
does not exist)
(/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/32w60ckf.kxh
does not exist) ---> System.IO.FileNotFoundException:
/home/smallette/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/hlxtywvr.c9b
does not exist

I guess the gremlin-dotnet/src/Gremlin.Net/Driver/obj/xdoc/cache directory
shouldn't be part of the zip (maybe not even
gremlin-dotnet/src/Gremlin.Net/Driver/obj).


On Thu, Jan 3, 2019 at 8:01 AM Daniel Kuppitz  wrote:

> Confirmed, building the tag just worked for me, too.
>
>
> On Thu, Jan 3, 2019 at 7:59 AM Robert Dale  wrote:
>
>> Building the tag from github works fine.  Looks like some local build
>> artifacts snuck into the src.zip.
>>
>> Excluding gremlin-dotnet, validate-distribution passes.
>>
>> Robert Dale
>>
>>
>> On Thu, Jan 3, 2019 at 9:49 AM Robert Dale  wrote:
>>
>> > Daniel, I had to install 'msbuild' in addition to the mono packages.  I
>> > also installed mono-addins-devel. I don't know if that actually did
>> > anything.
>> >
>> > But now I get some errors with :
>> >
>> > System.IO.FileNotFoundException:
>> */home/smallette*/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
>> > does not exist
>> >
>> >
>> > Robert Dale
>> >
>> >
>> > On Thu, Jan 3, 2019 at 9:43 AM Daniel Kuppitz  wrote:
>> >
>> >> I skimmed over the docs, they look good to me, but the
>> >> validate-distribution.sh script fails the same way as for Robert.
>> >>
>> >> Investigating
>> >>
>> >> Cheers,
>> >> Daniel
>> >>
>> >>
>> >> On Wed, Jan 2, 2019 at 2:58 PM Stephen Mallette 
>> >> wrote:
>> >>
>> >> > Hello,
>> >> >
>> >> > We are happy to announce that TinkerPop 3.3.5 is ready for release.
>> >> >
>> >> > The release artifacts can be found at this location:
>> >> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.5/
>> >> >
>> >> > The source distribution is provided by:
>> >> > apache-tinkerpop-3.3.5-src.zip
>> >> >
>> >> > Two binary distributions are provided for user convenience:
>> >> > apache-tinkerpop-gremlin-console-3.3.5-bin.zip
>> >> > apache-tinkerpop-gremlin-server-3.3.5-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.5/ (user docs)
>> >> > http://tinkerpop.apache.org/docs/3.3.5/upgrade/ (upgrade
>> docs)
>> >> > http://tinkerpop.apache.org/javadocs/3.3.5/core/ (core
>> javadoc)
>> >> > http://tinkerpop.apache.org/javadocs/3.3.5/full/ (full
>> javadoc)
>> >> >
>> >> > The tag in Apache Git can be found here:
>> >> > https://github.com/apache/tinkerpop/tree/3.3.5
>> >> >
>> >> > The release notes are available here:
>> >> >
>> >> https://github.com/apache/tinkerpop/blob/3.3.5/CHANGELOG.asciidoc
>> >> >
>> >> > The [VOTE] will be open for the next 72 hours --- closing Saturday
>> >> (January
>> >> > 5, 2018) at 5pm EST.
>> >> >
>> >> > My vote is +1.
>> >> >
>> >> > Thank you very much,
>> >> >
>> >> > Stephen
>> >> >
>> >>
>> >
>>
>

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

Confirmed, building the tag just worked for me, too.


On Thu, Jan 3, 2019 at 7:59 AM Robert Dale  wrote:

> Building the tag from github works fine.  Looks like some local build
> artifacts snuck into the src.zip.
>
> Excluding gremlin-dotnet, validate-distribution passes.
>
> Robert Dale
>
>
> On Thu, Jan 3, 2019 at 9:49 AM Robert Dale  wrote:
>
> > Daniel, I had to install 'msbuild' in addition to the mono packages.  I
> > also installed mono-addins-devel. I don't know if that actually did
> > anything.
> >
> > But now I get some errors with :
> >
> > System.IO.FileNotFoundException:
> */home/smallette*/git/apache/incubator-tinkerpop/gremlin-dotnet/src/obj/.cache/build/y2x4l8vu.n3b/2d1bhm1s.w5c
> > does not exist
> >
> >
> > Robert Dale
> >
> >
> > On Thu, Jan 3, 2019 at 9:43 AM Daniel Kuppitz  wrote:
> >
> >> I skimmed over the docs, they look good to me, but the
> >> validate-distribution.sh script fails the same way as for Robert.
> >>
> >> Investigating
> >>
> >> Cheers,
> >> Daniel
> >>
> >>
> >> On Wed, Jan 2, 2019 at 2:58 PM Stephen Mallette 
> >> wrote:
> >>
> >> > Hello,
> >> >
> >> > We are happy to announce that TinkerPop 3.3.5 is ready for release.
> >> >
> >> > The release artifacts can be found at this location:
> >> > https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.5/
> >> >
> >> > The source distribution is provided by:
> >> > apache-tinkerpop-3.3.5-src.zip
> >> >
> >> > Two binary distributions are provided for user convenience:
> >> > apache-tinkerpop-gremlin-console-3.3.5-bin.zip
> >> > apache-tinkerpop-gremlin-server-3.3.5-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.5/ (user docs)
> >> > http://tinkerpop.apache.org/docs/3.3.5/upgrade/ (upgrade
> docs)
> >> > http://tinkerpop.apache.org/javadocs/3.3.5/core/ (core
> javadoc)
> >> > http://tinkerpop.apache.org/javadocs/3.3.5/full/ (full
> javadoc)
> >> >
> >> > The tag in Apache Git can be found here:
> >> > https://github.com/apache/tinkerpop/tree/3.3.5
> >> >
> >> > The release notes are available here:
> >> >
> >> https://github.com/apache/tinkerpop/blob/3.3.5/CHANGELOG.asciidoc
> >> >
> >> > The [VOTE] will be open for the next 72 hours --- closing Saturday
> >> (January
> >> > 5, 2018) at 5pm EST.
> >> >
> >> > My vote is +1.
> >> >
> >> > Thank you very much,
> >> >
> >> > Stephen
> >> >
> >>
> >
>

Re: [VOTE] TinkerPop 3.3.5 Release

[Daniel Kuppitz]

I skimmed over the docs, they look good to me, but the
validate-distribution.sh script fails the same way as for Robert.

Investigating

Cheers,
Daniel


On Wed, Jan 2, 2019 at 2:58 PM Stephen Mallette 
wrote:

> Hello,
>
> We are happy to announce that TinkerPop 3.3.5 is ready for release.
>
> The release artifacts can be found at this location:
> https://dist.apache.org/repos/dist/dev/tinkerpop/3.3.5/
>
> The source distribution is provided by:
> apache-tinkerpop-3.3.5-src.zip
>
> Two binary distributions are provided for user convenience:
> apache-tinkerpop-gremlin-console-3.3.5-bin.zip
> apache-tinkerpop-gremlin-server-3.3.5-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.5/ (user docs)
> http://tinkerpop.apache.org/docs/3.3.5/upgrade/ (upgrade docs)
> http://tinkerpop.apache.org/javadocs/3.3.5/core/ (core javadoc)
> http://tinkerpop.apache.org/javadocs/3.3.5/full/ (full javadoc)
>
> The tag in Apache Git can be found here:
> https://github.com/apache/tinkerpop/tree/3.3.5
>
> The release notes are available here:
> https://github.com/apache/tinkerpop/blob/3.3.5/CHANGELOG.asciidoc
>
> The [VOTE] will be open for the next 72 hours --- closing Saturday (January
> 5, 2018) at 5pm EST.
>
> My vote is +1.
>
> Thank you very much,
>
> Stephen
>

[jira] [Created] (TINKERPOP-2124) InlineFilterStrategy produces wrong result

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2124:
-

 Summary: InlineFilterStrategy produces wrong result
 Key: TINKERPOP-2124
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2124
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


{noformat}
gremlin> g.V().hasLabel("person").
   or(and(has("age",gt(20)),
  has("age",lt(30))),
  and(has("age",gt(35)),
  has("age",lt(40.
 explain()
==>Traversal Explanation
=
Original Traversal [GraphStep(vertex,[]), 
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
  p([age.lt(40)])]])]])]

ConnectiveStrategy   [D]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
  p([age.lt(40)])]])]])]
CountStrategy[O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
  p([age.lt(40)])]])]])]
MatchPredicateStrategy   [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
  p([age.lt(40)])]])]])]
FilterRankingStrategy[O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person)]), OrStep([[AndStep([[HasStep([age.gt(20)])], 
[HasStep([age.lt(30)])]])], [AndStep([[HasStep([age.gt(35)])], [HasSte
  p([age.lt(40)])]])]])]
InlineFilterStrategy [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
IncidentToAdjacentStrategy   [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
AdjacentToIncidentStrategy   [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
RepeatUnrollStrategy [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
PathRetractionStrategy   [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
LazyBarrierStrategy  [O]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
TinkerGraphCountStrategy [P]   [GraphStep(vertex,[]), 
HasStep([~label.eq(person), age.or(gt(20), lt(30), gt(35), lt(40))])]
TinkerGraphStepStrategy  [P]   [TinkerGraphStep(vertex,[~label.eq(person), 
age.or(gt(20), lt(30), gt(35), lt(40))])]
ProfileStrategy  [F]   [TinkerGraphStep(vertex,[~label.eq(person), 
age.or(gt(20), lt(30), gt(35), lt(40))])]
StandardVerificationStrategy [V]   [TinkerGraphStep(vertex,[~label.eq(person), 
age.or(gt(20), lt(30), gt(35), lt(40))])]

Final Traversal[TinkerGraphStep(vertex,[~label.eq(person), 
age.or(gt(20), lt(30), gt(35), lt(40))])]
{noformat}



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

Re: [DISCUSS] code freeze 3.2.11/3.3.5/3.4.0

[Daniel Kuppitz]

A quick & dirty fix for the broken radish libs to at least get a clean
build in docker:

diff --git a/docker/scripts/build.sh b/docker/scripts/build.sh
index e172ddaaa9..8b56cf53c3 100755
--- a/docker/scripts/build.sh
+++ b/docker/scripts/build.sh
*@@ -78,7 +78,10 @@* if [ -r "settings.xml" ]; then
   cp settings.xml ~/.m2/
 fi

*-mvn clean install process-resources ${TINKERPOP_BUILD_OPTIONS} || exit 1*
*+mvn clean install -DskipTests*
*+sed -i 's/background=background,/background=background/g'
gremlin-python/target/python2/env/local/lib/python2.7/site-packages/radish/parser.py*
*+*
+mvn install process-resources ${TINKERPOP_BUILD_OPTIONS} || exit 1
 [ -z "${BUILD_JAVA_DOCS}" ] || mvn process-resources -Djavadoc || exit 1

 if [ ! -z "${BUILD_USER_DOCS}" ]; then



Cheers,
Daniel


On Thu, Dec 27, 2018 at 6:18 AM Stephen Mallette 
wrote:

> Hi all, just checking in during the holiday period. My laptop will return
> to the off position shortly, but I wanted to point out that we seem to have
> a problem with Python:
>
> https://travis-ci.org/apache/tinkerpop/jobs/472444735
>
> every current PR seems to be in fail mode right now. We will want to sort
> that out before release.Looks like something in radish. If anyone can have
> a look this week that would be helpful as I won't have time to dig on it
> too deeply until next week (which is when we are supposed to be releasing).
>
> On Mon, Dec 17, 2018 at 7:09 AM Stephen Mallette 
> wrote:
>
> > While I think we could go on for every adding things to 3.4.0 I think
> it's
> > time to cut it off and release. There's too many good things in there to
> > hold for any longer. We are looking at releasing 3.2.11, 3.3.5 and 3.4.0.
> >
> > I'd propose we polish up remaining items this week, set for code freeze
> > 12/22 and then build the release for VOTE the week of the 31st. I assume
> > that there are enough PMC members around the holiday period to VOTE on
> the
> > release artifacts. If the VOTE has to stay open a bit longer than is
> > typical then that's ok. I'm happy to just do all three releases myself
> this
> > time as it might be hard to coordinate with others during the holiday
> > period.
> >
> > We still have a number of important things to finish - specifically:
> >
> > 1. code reviews on open PRs with ids > 1000
> > 2. finish up the GraphBinary - jorge is adding two more serializers and
> > then i think we can call this a day and put it up for review.
> > 3. documentation review
> > 4. anything else?
> >
> > As usual, let's continue to use this thread for release coordination
> > heading into code freeze.
> >
> >
> >
>

[jira] [Closed] (TINKERPOP-1849) Provide a way to fold() with an index

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-1849.
-
   Resolution: Fixed
Fix Version/s: 3.4.0

> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0
>
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin> 
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
>  select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we 
> can add an option to {{fold()}} that would take an enum of "fold operators".



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

[jira] [Closed] (TINKERPOP-2114) Document common Gremlin anti-patterns

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2114.
-
   Resolution: Fixed
Fix Version/s: 3.3.5
   3.4.0

> Document common Gremlin anti-patterns
> -
>
> Key: TINKERPOP-2114
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2114
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.3.4
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>




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

[jira] [Created] (TINKERPOP-2114) Document common Gremlin anti-patterns

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2114:
-

 Summary: Document common Gremlin anti-patterns
 Key: TINKERPOP-2114
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2114
 Project: TinkerPop
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz






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

[jira] [Created] (TINKERPOP-2112) Folding in property() step is screwed

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2112:
-

 Summary: Folding in property() step is screwed
 Key: TINKERPOP-2112
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2112
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


Somehow we mess up the folding in {{property()}} step when it's used with 
tokens. I think there's just a missing {{if}} branch, but needs further 
investigation.

{noformat}
gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV().property(T.id , 'id').property(single, 'k', 'v')
==>v[id]
gremlin> g.addV().property(single, 'k', 'v').property(T.id , 'id')
org.apache.tinkerpop.gremlin.structure.T$2 cannot be cast to java.lang.String
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}

{noformat}
gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV().property(T.id , 'id').property(single, 'k', 'v').explain()
==>Traversal Explanation
=
Original Traversal [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]

ConnectiveStrategy   [D]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
MatchPredicateStrategy   [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
FilterRankingStrategy[O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
InlineFilterStrategy [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
IncidentToAdjacentStrategy   [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
AdjacentToIncidentStrategy   [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
RepeatUnrollStrategy [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
PathRetractionStrategy   [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
CountStrategy[O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
LazyBarrierStrategy  [O]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
TinkerGraphCountStrategy [P]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
TinkerGraphStepStrategy  [P]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
ProfileStrategy  [F]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
StandardVerificationStrategy [V]   [AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]

Final Traversal[AddVertexStartStep({id=[id]}), 
AddPropertyStep({key=[k], value=[v]})]
gremlin> g.addV().property(single, 'k', 'v').property(T.id , 'id').explain()
==>Traversal Explanation
===
Original Traversal [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]

ConnectiveStrategy   [D]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
MatchPredicateStrategy   [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
FilterRankingStrategy[O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
InlineFilterStrategy [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
IncidentToAdjacentStrategy   [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
AdjacentToIncidentStrategy   [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
RepeatUnrollStrategy [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
PathRetractionStrategy   [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
CountStrategy[O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[v]}), AddPropertyStep({key=[id], value=[id]})]
LazyBarrierStrategy  [O]   [AddVertexStartStep({}), 
AddPropertyStep({key=[k], value=[

[jira] [Comment Edited] (TINKERPOP-1849) Provide a way to fold() with an index

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz edited comment on TINKERPOP-1849 at 12/4/18 9:58 PM:


I don't know when I will start to work on this, so - as a reminder - here are 
just the thoughts from our latest discussion:

We should only implement a local version of this step, because

# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory 
consumption
# it will just work in OLTP and OLAP

This is how could look like:

{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().with(WithOptions.indexer, WithOptions.map)
==>[0:v[1],1:v[2],2:v[3],3:v[4],4:v[5],5:v[6]]
{noformat}


was (Author: dkuppitz):
I don't know when I will start to work on this, so - as a reminder - here are 
just the thoughts from our latest discussion:

We should only implement a local version of this step, because

# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory 
consumption
# it will just work in OLTP and OLAP

This is how could look like:

{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().by('e').by('i')
==>[[e:v[1],i:0],[e:v[2],i:1],[e:v[3],i:2],[e:v[4],i:3],[e:v[5],i:4],[e:v[6],i:5]]
{noformat}

> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin> 
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
>  select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we 
> can add an option to {{fold()}} that would take an enum of "fold operators".



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

[jira] [Closed] (TINKERPOP-2100) coalesce() creating unexpected results when used with order()

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2100.
-
   Resolution: Fixed
Fix Version/s: 3.3.5
   3.4.0

> coalesce() creating unexpected results when used with order()
> -
>
> Key: TINKERPOP-2100
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2100
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.4
>Reporter: stephen mallette
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> Bug was originally reported here:
> https://stackoverflow.com/q/53482054/1831717
> demonstrated as:
> {code}
> gremlin> g.V().
> ..1>   hasLabel("person").
> ..2>   out("created").
> ..3>   order().by("name").
> ..4>   coalesce(values("name").fold(), constant("x")).
> ..5>   fold()
> ==>[[lop,lop,lop],[lop,lop,lop],[lop,lop,lop],[ripple]]
> {code}



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

[jira] [Created] (TINKERPOP-2107) Spark fails to reattach properties

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2107:
-

 Summary: Spark fails to reattach properties
 Key: TINKERPOP-2107
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2107
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz


The traversal {{g.V().outE().properties().dedup()}} throws a 
{{NullPointerException}} when run in Spark OLAP. I created a branch for this 
ticket and added a failing test.



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

[jira] [Closed] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2095.
-
   Resolution: Fixed
Fix Version/s: 3.3.5
   3.4.0

> GroupStep looks for irrelevant barrier steps
> 
>
> Key: TINKERPOP-2095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.4
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.4.0, 3.3.5
>
>
> {{GroupStep}} looks for a {{Barrier}} step to determine the reducing 
> bi-operator. This is wrong and I'm really surprised that this has never been 
> spotted before.
> {noformat}
> gremlin> 
> g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
> java.lang.Long cannot be cast to 
> org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> In the query above the first barrier step is a {{NoOpBarrier}} step (added by 
> {{PathRetractionStrategy}}). This step obviously has no reducing bi-operator. 
> What we really want to do is look for the first barrier step that is not a 
> {{LocalBarrier}} step.



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

[jira] [Updated] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2095:
--
Description: 
{{GroupStep}} looks for a {{Barrier}} step to determine the reducing 
bi-operator. This is wrong and I'm really surprised that this has never been 
spotted before.

{noformat}
gremlin> 
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to 
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}

In the query above the first barrier step is a {{NoOpBarrier}} step (added by 
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator. 
What we really want to do is look for the first barrier step that is not a 
{{LocalBarrier}} step.

  was:
{{GroupStep}} looks for {{Barrier}} step to determine the reducing bi-operator. 
This is wrong and I'm really surprised that this has never been spotted before.

{noformat}
gremlin> 
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to 
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}

In the query above the first barrier step is a {{NoOpBarrier}} step (added by 
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator. 
What we really want to do is look for the first reducing barrier step.


> GroupStep looks for irrelevant barrier steps
> 
>
> Key: TINKERPOP-2095
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
> Project: TinkerPop
>  Issue Type: Bug
>  Components: process
>Affects Versions: 3.3.4
>Reporter: Daniel Kuppitz
>Assignee: Daniel Kuppitz
>Priority: Major
>
> {{GroupStep}} looks for a {{Barrier}} step to determine the reducing 
> bi-operator. This is wrong and I'm really surprised that this has never been 
> spotted before.
> {noformat}
> gremlin> 
> g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
> java.lang.Long cannot be cast to 
> org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
> Type ':help' or ':h' for help.
> Display stack trace? [yN]
> {noformat}
> In the query above the first barrier step is a {{NoOpBarrier}} step (added by 
> {{PathRetractionStrategy}}). This step obviously has no reducing bi-operator. 
> What we really want to do is look for the first barrier step that is not a 
> {{LocalBarrier}} step.



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

[jira] [Created] (TINKERPOP-2095) GroupStep looks for irrelevant barrier steps

[Daniel Kuppitz (JIRA)]

Daniel Kuppitz created TINKERPOP-2095:
-

 Summary: GroupStep looks for irrelevant barrier steps
 Key: TINKERPOP-2095
 URL: https://issues.apache.org/jira/browse/TINKERPOP-2095
 Project: TinkerPop
  Issue Type: Bug
  Components: process
Affects Versions: 3.3.4
Reporter: Daniel Kuppitz
Assignee: Daniel Kuppitz


{{GroupStep}} looks for {{Barrier}} step to determine the reducing bi-operator. 
This is wrong and I'm really surprised that this has never been spotted before.

{noformat}
gremlin> 
g.V().hasLabel('person').as('p').out('created').group().by('name').by(select('p').values('age').sum())
java.lang.Long cannot be cast to 
org.apache.tinkerpop.gremlin.process.traversal.traverser.util.TraverserSet
Type ':help' or ':h' for help.
Display stack trace? [yN]
{noformat}

In the query above the first barrier step is a {{NoOpBarrier}} step (added by 
{{PathRetractionStrategy}}). This step obviously has no reducing bi-operator. 
What we really want to do is look for the first reducing barrier step.



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

Re: Uniqueness of property ids

[Daniel Kuppitz]

Spark was the very first thing that failed - I think it was only the newly
added test
<https://github.com/apache/tinkerpop/pull/993/files#diff-7b625ebb74c59ffe5521b63a49797b64R169>,
but of course, the failure made sense as this query can't work if the
parent element's id lost somewhere down the line.
So, in one way or another, we have to remember the parent id if we want to
allow local property id uniqueness.

Cheers,
Daniel


On Tue, Nov 13, 2018 at 7:50 PM Stephen Mallette 
wrote:

> Gryo is so completely inflexible some times :|
>
> How did we end up having to do this again? Reading back through the thread,
> it seemed like it was because of Spark testing. What kinds of tests were
> failing for Spark because of this? I assume it wasn't just property
> assertions in the tests themselves, right? Or was Spark just blowing up and
> erroring out?
>
> On Tue, Nov 13, 2018 at 10:10 AM Daniel Kuppitz  wrote:
>
> > That was my conclusion as well, I didn't see a way to make it
> non-breaking.
> > Maybe 3.4.0 should just have a special serializer for VertexProperties..?
> >
> >
> > On Tue, Nov 13, 2018 at 5:00 AM Stephen Mallette 
> > wrote:
> >
> > > If i'm thinking about this rightI guess Gryo used the default Kryo
> > > serialization for 1.0 and 3.0 so  by changing that we effectively break
> > > both version of Gryo in 3.4.0. And that would mean that you couldn't
> > > connect to older versions of the Java driver to 3.4.0 systems - you
> would
> > > have to upgrade. Is that the correct conclusion?
> > >
> > > On Mon, Nov 12, 2018 at 9:28 AM Daniel Kuppitz 
> wrote:
> > >
> > > > I actually opened a PR <https://github.com/apache/tinkerpop/pull/993
> >
> > > > (makes it easier to look at the changes). Removing transient didn't
> > quite
> > > > do the job, so I overwrote the (de)serialization methods and only
> kept
> > > the
> > > > parent element id. The only thing that's broken now is the
> > serialization
> > > > test suite.
> > > >
> > > > Cheers,
> > > > Daniel
> > > >
> > > >
> > > > On Mon, Nov 12, 2018 at 4:59 AM Stephen Mallette <
> spmalle...@gmail.com
> > >
> > > > wrote:
> > > >
> > > > > I don't think we can remove the transient keyword. Doesn't that
> > balloon
> > > > the
> > > > > amount of data shuffled around the network? I think that was the
> > reason
> > > > we
> > > > > made that transient in the first place.
> > > > >
> > > > > What parts of the test suite are failing because of this? Could you
> > > post
> > > > > links to a couple of examples of failing assertions?
> > > > >
> > > > > On Sat, Nov 10, 2018 at 2:01 PM Daniel Kuppitz 
> > > wrote:
> > > > >
> > > > > > Removing the transient attribute from the
> DetachedVertexProperty's
> > > > vertex
> > > > > > field [1] makes all Spark tests pass. Easy peasy, but holy cow,
> > that
> > > > > little
> > > > > > change probably has a huge impact on things I can't even think of
> > > right
> > > > > > now.
> > > > > >
> > > > > > [1]
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/detached/DetachedVertexProperty.java#L40
> > > > > >
> > > > > > Cheers,
> > > > > > Daniel
> > > > > >
> > > > > >
> > > > > > On Sat, Nov 10, 2018 at 11:49 AM Daniel Kuppitz  >
> > > > wrote:
> > > > > >
> > > > > > > Treating null parents as a wildcard makes the majority of tests
> > > just
> > > > > > pass,
> > > > > > > but Spark integration tests fail. Spark is all about detached
> > > > elements
> > > > > > (or
> > > > > > > reference elements) and I guess there's no way to make those
> > tests
> > > > pass
> > > > > > > without making detached properties remember their parent
> elements
> > > (or
> > > > > at
> > > > > > > least just their parent ele

Re: Uniqueness of property ids

[Daniel Kuppitz]

That was my conclusion as well, I didn't see a way to make it non-breaking.
Maybe 3.4.0 should just have a special serializer for VertexProperties..?


On Tue, Nov 13, 2018 at 5:00 AM Stephen Mallette 
wrote:

> If i'm thinking about this rightI guess Gryo used the default Kryo
> serialization for 1.0 and 3.0 so  by changing that we effectively break
> both version of Gryo in 3.4.0. And that would mean that you couldn't
> connect to older versions of the Java driver to 3.4.0 systems - you would
> have to upgrade. Is that the correct conclusion?
>
> On Mon, Nov 12, 2018 at 9:28 AM Daniel Kuppitz  wrote:
>
> > I actually opened a PR <https://github.com/apache/tinkerpop/pull/993>
> > (makes it easier to look at the changes). Removing transient didn't quite
> > do the job, so I overwrote the (de)serialization methods and only kept
> the
> > parent element id. The only thing that's broken now is the serialization
> > test suite.
> >
> > Cheers,
> > Daniel
> >
> >
> > On Mon, Nov 12, 2018 at 4:59 AM Stephen Mallette 
> > wrote:
> >
> > > I don't think we can remove the transient keyword. Doesn't that balloon
> > the
> > > amount of data shuffled around the network? I think that was the reason
> > we
> > > made that transient in the first place.
> > >
> > > What parts of the test suite are failing because of this? Could you
> post
> > > links to a couple of examples of failing assertions?
> > >
> > > On Sat, Nov 10, 2018 at 2:01 PM Daniel Kuppitz 
> wrote:
> > >
> > > > Removing the transient attribute from the DetachedVertexProperty's
> > vertex
> > > > field [1] makes all Spark tests pass. Easy peasy, but holy cow, that
> > > little
> > > > change probably has a huge impact on things I can't even think of
> right
> > > > now.
> > > >
> > > > [1]
> > > >
> > > >
> > >
> >
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/detached/DetachedVertexProperty.java#L40
> > > >
> > > > Cheers,
> > > > Daniel
> > > >
> > > >
> > > > On Sat, Nov 10, 2018 at 11:49 AM Daniel Kuppitz 
> > wrote:
> > > >
> > > > > Treating null parents as a wildcard makes the majority of tests
> just
> > > > pass,
> > > > > but Spark integration tests fail. Spark is all about detached
> > elements
> > > > (or
> > > > > reference elements) and I guess there's no way to make those tests
> > pass
> > > > > without making detached properties remember their parent elements
> (or
> > > at
> > > > > least just their parent element ids).
> > > > >
> > > > > Cheers,
> > > > > Daniel
> > > > >
> > > > >
> > > > > On Fri, Nov 9, 2018 at 4:53 AM Stephen Mallette <
> > spmalle...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >> If we can, I think that we should just keep derser semantics as
> they
> > > > are.
> > > > >> We've gone this long with them having null parent element ids and
> > > there
> > > > >> haven't been any raised complains that I'm aware of.
> > > > >>
> > > > >> > I thought about skipping the parent id comparison in case one of
> > the
> > > > >> elements parents is *null*
> > > > >>
> > > > >> I suppose the question we need to answer stated directly is: What
> do
> > > we
> > > > >> want equals() to mean for "detached" properties? Maybe it's not
> > wrong
> > > to
> > > > >> consider "detached" properties without a parent to have a form of
> > > > wildcard
> > > > >> status. If you were to "attach" such a property then its id space
> > > would
> > > > be
> > > > >> restricted to the element you're adding it to, so it seems safe in
> > > that
> > > > >> respect. In the "tree test" that's failing that you referenced,
> the
> > > > >> deserialized tree is a wildcard match for the original tree...the
> > idea
> > > > >> sorta works in that capacity, but perhaps there are other
> sc

Re: Uniqueness of property ids

[Daniel Kuppitz]

I actually opened a PR <https://github.com/apache/tinkerpop/pull/993>
(makes it easier to look at the changes). Removing transient didn't quite
do the job, so I overwrote the (de)serialization methods and only kept the
parent element id. The only thing that's broken now is the serialization
test suite.

Cheers,
Daniel


On Mon, Nov 12, 2018 at 4:59 AM Stephen Mallette 
wrote:

> I don't think we can remove the transient keyword. Doesn't that balloon the
> amount of data shuffled around the network? I think that was the reason we
> made that transient in the first place.
>
> What parts of the test suite are failing because of this? Could you post
> links to a couple of examples of failing assertions?
>
> On Sat, Nov 10, 2018 at 2:01 PM Daniel Kuppitz  wrote:
>
> > Removing the transient attribute from the DetachedVertexProperty's vertex
> > field [1] makes all Spark tests pass. Easy peasy, but holy cow, that
> little
> > change probably has a huge impact on things I can't even think of right
> > now.
> >
> > [1]
> >
> >
> https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/detached/DetachedVertexProperty.java#L40
> >
> > Cheers,
> > Daniel
> >
> >
> > On Sat, Nov 10, 2018 at 11:49 AM Daniel Kuppitz  wrote:
> >
> > > Treating null parents as a wildcard makes the majority of tests just
> > pass,
> > > but Spark integration tests fail. Spark is all about detached elements
> > (or
> > > reference elements) and I guess there's no way to make those tests pass
> > > without making detached properties remember their parent elements (or
> at
> > > least just their parent element ids).
> > >
> > > Cheers,
> > > Daniel
> > >
> > >
> > > On Fri, Nov 9, 2018 at 4:53 AM Stephen Mallette 
> > > wrote:
> > >
> > >> If we can, I think that we should just keep derser semantics as they
> > are.
> > >> We've gone this long with them having null parent element ids and
> there
> > >> haven't been any raised complains that I'm aware of.
> > >>
> > >> > I thought about skipping the parent id comparison in case one of the
> > >> elements parents is *null*
> > >>
> > >> I suppose the question we need to answer stated directly is: What do
> we
> > >> want equals() to mean for "detached" properties? Maybe it's not wrong
> to
> > >> consider "detached" properties without a parent to have a form of
> > wildcard
> > >> status. If you were to "attach" such a property then its id space
> would
> > be
> > >> restricted to the element you're adding it to, so it seems safe in
> that
> > >> respect. In the "tree test" that's failing that you referenced, the
> > >> deserialized tree is a wildcard match for the original tree...the idea
> > >> sorta works in that capacity, but perhaps there are other scenarios
> > where
> > >> that's a really bad thing?
> > >>
> > >> Does a "null" parent element mean "detached"? I guess the answer is
> > >> "sometimes" because in some cases "detached" keeps the parent element.
> > Are
> > >> there other scenarios though where the parent element can be null? I
> > can't
> > >> really think of any right now.
> > >>
> > >> On Thu, Nov 8, 2018 at 12:48 PM Daniel Kuppitz 
> wrote:
> > >>
> > >> > Working on TINKERPOP-2051
> > >> > <https://issues.apache.org/jira/browse/TINKERPOP-2051>, I thought I
> > >> found
> > >> > a
> > >> > pretty easy solution: In order to allow locally unique property ids,
> > we
> > >> > only need to compare the ids of two properties as well as the ids of
> > >> their
> > >> > parent elements. That was basically a one-line change and had the
> > >> expected
> > >> > effect:
> > >> >
> > >> >
> > >> > gremlin> g = TinkerGraph.open().traversal()
> > >> > ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> > >> > gremlin> g.addV("person").property("name", "alice", id,
> > "name").as("a").
> > >> > ..1>   addV("person").property("name"

[jira] [Assigned] (TINKERPOP-2051) Uniqueness of property ids

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz reassigned TINKERPOP-2051:
-

Assignee: Daniel Kuppitz

> Uniqueness of property ids
> --
>
> Key: TINKERPOP-2051
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2051
> Project: TinkerPop
>  Issue Type: Bug
>  Components: structure
>Affects Versions: 3.2.9
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> Right now we don't ensure property id uniqueness. As shown in [this 
> discussion|https://lists.apache.org/thread.html/e28d61e1f3b674b617765a0f28174d45691db0812e7c56761d1456c3@%3Cdev.tinkerpop.apache.org%3E],
>  this can lead to very odd results, hence I marked this ticket as a Bug.



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

Re: Uniqueness of property ids

[Daniel Kuppitz]

Removing the transient attribute from the DetachedVertexProperty's vertex
field [1] makes all Spark tests pass. Easy peasy, but holy cow, that little
change probably has a huge impact on things I can't even think of right now.

[1]
https://github.com/apache/tinkerpop/blob/master/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/structure/util/detached/DetachedVertexProperty.java#L40

Cheers,
Daniel


On Sat, Nov 10, 2018 at 11:49 AM Daniel Kuppitz  wrote:

> Treating null parents as a wildcard makes the majority of tests just pass,
> but Spark integration tests fail. Spark is all about detached elements (or
> reference elements) and I guess there's no way to make those tests pass
> without making detached properties remember their parent elements (or at
> least just their parent element ids).
>
> Cheers,
> Daniel
>
>
> On Fri, Nov 9, 2018 at 4:53 AM Stephen Mallette 
> wrote:
>
>> If we can, I think that we should just keep derser semantics as they are.
>> We've gone this long with them having null parent element ids and there
>> haven't been any raised complains that I'm aware of.
>>
>> > I thought about skipping the parent id comparison in case one of the
>> elements parents is *null*
>>
>> I suppose the question we need to answer stated directly is: What do we
>> want equals() to mean for "detached" properties? Maybe it's not wrong to
>> consider "detached" properties without a parent to have a form of wildcard
>> status. If you were to "attach" such a property then its id space would be
>> restricted to the element you're adding it to, so it seems safe in that
>> respect. In the "tree test" that's failing that you referenced, the
>> deserialized tree is a wildcard match for the original tree...the idea
>> sorta works in that capacity, but perhaps there are other scenarios where
>> that's a really bad thing?
>>
>> Does a "null" parent element mean "detached"? I guess the answer is
>> "sometimes" because in some cases "detached" keeps the parent element. Are
>> there other scenarios though where the parent element can be null? I can't
>> really think of any right now.
>>
>> On Thu, Nov 8, 2018 at 12:48 PM Daniel Kuppitz  wrote:
>>
>> > Working on TINKERPOP-2051
>> > <https://issues.apache.org/jira/browse/TINKERPOP-2051>, I thought I
>> found
>> > a
>> > pretty easy solution: In order to allow locally unique property ids, we
>> > only need to compare the ids of two properties as well as the ids of
>> their
>> > parent elements. That was basically a one-line change and had the
>> expected
>> > effect:
>> >
>> >
>> > gremlin> g = TinkerGraph.open().traversal()
>> > ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
>> > gremlin> g.addV("person").property("name", "alice", id, "name").as("a").
>> > ..1>   addV("person").property("name", "bob", id, "name").
>> > ..2>   addE("knows").from("a")
>> > ==>e[2][0-knows->1]
>> > gremlin>
>> > gremlin> g.V().properties("name")
>> > ==>vp[name->alice]
>> > ==>vp[name->bob]
>> > gremlin> g.V().properties("name").dedup()
>> > ==>vp[name->alice]
>> > ==>vp[name->bob]
>> >
>> >
>> > Without the change in id comparison, the last statement would have only
>> > returned 1 of the properties. Looked easy enough, but - of course - it
>> > broke the test suite. This change had an impact on 2 types of tests:
>> >
>> >- those, that deal with serialization and deserialization
>> >- those, that make use of bytecode
>> >
>> > Perhaps the latter can be seen as a more specific case of the former.
>> The
>> > problem is that serialized/deserialized/detached properties no longer
>> have
>> > a reference to their former parent element. I thought about skipping the
>> > parent id comparison in case one of the elements parents is *null*, but
>> at
>> > some point that just felt wrong and made me think of all kind of horror
>> > scenarios this could/would lead to.
>> >
>> > So my question is, what would be the smartest way to handle that? Adjust
>> > all test cases, so they no longer rely on full equality? Fix
>> > (de)serialization to include parent element ids? Something else?
>> >
>> > *Example of a failing test:*
>> >
>> > [ERROR]   SerializationTest$GryoV1d0Test.shouldSerializeTree:254 The
>> > objects differ
>> > expected:
>> >
>> >
>> org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[1]={v[2]={vp[name->vadas]={}},
>> > v[3]={vp[name->lop]={}}, v[4]={vp[name->josh]={>
>> > but was:
>> >
>> >
>> org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[1]={v[2]={vp[name->vadas]={}},
>> > v[3]={vp[name->lop]={}}, v[4]={vp[name->josh]={>
>> >
>> >
>> > Crazy thought: We could just change the tests to compare the toString()
>> > versions of results
>> >
>> > Cheers,
>> > Daniel
>> >
>>
>

Re: Uniqueness of property ids

[Daniel Kuppitz]

Treating null parents as a wildcard makes the majority of tests just pass,
but Spark integration tests fail. Spark is all about detached elements (or
reference elements) and I guess there's no way to make those tests pass
without making detached properties remember their parent elements (or at
least just their parent element ids).

Cheers,
Daniel


On Fri, Nov 9, 2018 at 4:53 AM Stephen Mallette 
wrote:

> If we can, I think that we should just keep derser semantics as they are.
> We've gone this long with them having null parent element ids and there
> haven't been any raised complains that I'm aware of.
>
> > I thought about skipping the parent id comparison in case one of the
> elements parents is *null*
>
> I suppose the question we need to answer stated directly is: What do we
> want equals() to mean for "detached" properties? Maybe it's not wrong to
> consider "detached" properties without a parent to have a form of wildcard
> status. If you were to "attach" such a property then its id space would be
> restricted to the element you're adding it to, so it seems safe in that
> respect. In the "tree test" that's failing that you referenced, the
> deserialized tree is a wildcard match for the original tree...the idea
> sorta works in that capacity, but perhaps there are other scenarios where
> that's a really bad thing?
>
> Does a "null" parent element mean "detached"? I guess the answer is
> "sometimes" because in some cases "detached" keeps the parent element. Are
> there other scenarios though where the parent element can be null? I can't
> really think of any right now.
>
> On Thu, Nov 8, 2018 at 12:48 PM Daniel Kuppitz  wrote:
>
> > Working on TINKERPOP-2051
> > <https://issues.apache.org/jira/browse/TINKERPOP-2051>, I thought I
> found
> > a
> > pretty easy solution: In order to allow locally unique property ids, we
> > only need to compare the ids of two properties as well as the ids of
> their
> > parent elements. That was basically a one-line change and had the
> expected
> > effect:
> >
> >
> > gremlin> g = TinkerGraph.open().traversal()
> > ==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
> > gremlin> g.addV("person").property("name", "alice", id, "name").as("a").
> > ..1>   addV("person").property("name", "bob", id, "name").
> > ..2>   addE("knows").from("a")
> > ==>e[2][0-knows->1]
> > gremlin>
> > gremlin> g.V().properties("name")
> > ==>vp[name->alice]
> > ==>vp[name->bob]
> > gremlin> g.V().properties("name").dedup()
> > ==>vp[name->alice]
> > ==>vp[name->bob]
> >
> >
> > Without the change in id comparison, the last statement would have only
> > returned 1 of the properties. Looked easy enough, but - of course - it
> > broke the test suite. This change had an impact on 2 types of tests:
> >
> >- those, that deal with serialization and deserialization
> >- those, that make use of bytecode
> >
> > Perhaps the latter can be seen as a more specific case of the former. The
> > problem is that serialized/deserialized/detached properties no longer
> have
> > a reference to their former parent element. I thought about skipping the
> > parent id comparison in case one of the elements parents is *null*, but
> at
> > some point that just felt wrong and made me think of all kind of horror
> > scenarios this could/would lead to.
> >
> > So my question is, what would be the smartest way to handle that? Adjust
> > all test cases, so they no longer rely on full equality? Fix
> > (de)serialization to include parent element ids? Something else?
> >
> > *Example of a failing test:*
> >
> > [ERROR]   SerializationTest$GryoV1d0Test.shouldSerializeTree:254 The
> > objects differ
> > expected:
> >
> >
> org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[1]={v[2]={vp[name->vadas]={}},
> > v[3]={vp[name->lop]={}}, v[4]={vp[name->josh]={>
> > but was:
> >
> >
> org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[1]={v[2]={vp[name->vadas]={}},
> > v[3]={vp[name->lop]={}}, v[4]={vp[name->josh]={>
> >
> >
> > Crazy thought: We could just change the tests to compare the toString()
> > versions of results
> >
> > Cheers,
> > Daniel
> >
>

[jira] [Closed] (TINKERPOP-2059) Modulation of valueMap()

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2059.
-
   Resolution: Fixed
Fix Version/s: 3.4.0

> Modulation of valueMap()
> 
>
> Key: TINKERPOP-2059
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2059
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.3
>Reporter: stephen mallette
>    Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
> Fix For: 3.4.0
>
>
> Allow for modulation of the {{valueMap()}} step with {{by()}} and possibly 
> {{with()}} to make it's usage more flexible and consistent. The problem 
> presented in relation to this change is how to easily unwrap the general 
> multi-property structure of {{valueMap()}}
> {code}
> g.V().has('person','name','marko').
>   valueMap('name','age').
> by(unfold())
> {code}
> which would yield: {{[name:marko,age:29]}} rather than: 
> {{[name:[marko],age:[29]]}}. Obviously the {{by()}} is just a map over the 
> values in the list of values returned from properties. 
> Please see the 
> [DISCUSS|https://lists.apache.org/thread.html/91a3c980b5968c78638383dfa11f44ee14fc114ddc3d29e762e56f1f@%3Cdev.tinkerpop.apache.org%3E]
>  thread for additional thoughts on the matter to consider.



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

[jira] [Commented] (TINKERPOP-1849) Provide a way to fold() with an index

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1849:
---

I don't know when I will start to work on this, so - as a reminder - here are 
just the thoughts from our latest discussion:

We should only implement a local version of this step, because

# it's not too much to ask a user to do the {{fold()}}
# by explicitly using {{fold()}} the user is made aware of the memory 
consumption
# it will just work in OLTP and OLAP

This is how could look like:

{noformat}
gremlin> g.V().index()
==>[v[1], 0]
==>[v[2], 0]
==>[v[3], 0]
==>[v[4], 0]
==>[v[5], 0]
==>[v[6], 0]
gremlin> g.V().fold().index()
==>[[v[1],0],[v[2],1],[v[3],2],[v[4],3],[v[5],4],[v[6],5]]
gremlin> g.V().fold().index().by('e').by('i')
==>[[e:v[1],i:0],[e:v[2],i:1],[e:v[3],i:2],[e:v[4],i:3],[e:v[5],i:4],[e:v[6],i:5]]
{noformat}

> Provide a way to fold() with an index
> -
>
> Key: TINKERPOP-1849
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1849
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>    Affects Versions: 3.3.0
>Reporter: stephen mallette
>Assignee: Daniel Kuppitz
>Priority: Major
>
> In Groovy you can call {{withIndex()}} to generate output like this:
> {code}
> gremlin> g.V().fold().next().withIndex()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> We can currently simulate this with Gremlin via:
> {code}
> gremlin> 
> g.V().project("a","b").by().by(select("x").count(local)).store("x").map(union(select('a'),
>  select('b')).fold()).fold().next()
> ==>[v[1],0]
> ==>[v[2],1]
> ==>[v[3],2]
> ==>[v[4],3]
> ==>[v[5],4]
> ==>[v[6],5]
> {code}
> but it's not easy to follow, efficient, or potentially foolproof. Perhaps we 
> can add an option to {{fold()}} that would take an enum of "fold operators".



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

Uniqueness of property ids

[Daniel Kuppitz]

Working on TINKERPOP-2051
, I thought I found a
pretty easy solution: In order to allow locally unique property ids, we
only need to compare the ids of two properties as well as the ids of their
parent elements. That was basically a one-line change and had the expected
effect:


gremlin> g = TinkerGraph.open().traversal()
==>graphtraversalsource[tinkergraph[vertices:0 edges:0], standard]
gremlin> g.addV("person").property("name", "alice", id, "name").as("a").
..1>   addV("person").property("name", "bob", id, "name").
..2>   addE("knows").from("a")
==>e[2][0-knows->1]
gremlin>
gremlin> g.V().properties("name")
==>vp[name->alice]
==>vp[name->bob]
gremlin> g.V().properties("name").dedup()
==>vp[name->alice]
==>vp[name->bob]


Without the change in id comparison, the last statement would have only
returned 1 of the properties. Looked easy enough, but - of course - it
broke the test suite. This change had an impact on 2 types of tests:

   - those, that deal with serialization and deserialization
   - those, that make use of bytecode

Perhaps the latter can be seen as a more specific case of the former. The
problem is that serialized/deserialized/detached properties no longer have
a reference to their former parent element. I thought about skipping the
parent id comparison in case one of the elements parents is *null*, but at
some point that just felt wrong and made me think of all kind of horror
scenarios this could/would lead to.

So my question is, what would be the smartest way to handle that? Adjust
all test cases, so they no longer rely on full equality? Fix
(de)serialization to include parent element ids? Something else?

*Example of a failing test:*

[ERROR]   SerializationTest$GryoV1d0Test.shouldSerializeTree:254 The
objects differ
expected:
org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[1]={v[2]={vp[name->vadas]={}},
v[3]={vp[name->lop]={}}, v[4]={vp[name->josh]={>
but was:
org.apache.tinkerpop.gremlin.process.traversal.step.util.Tree<{v[1]={v[2]={vp[name->vadas]={}},
v[3]={vp[name->lop]={}}, v[4]={vp[name->josh]={>


Crazy thought: We could just change the tests to compare the toString()
versions of results

Cheers,
Daniel

[jira] [Updated] (TINKERPOP-2059) Modulation of valueMap()

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz updated TINKERPOP-2059:
--
Labels: breaking  (was: )

> Modulation of valueMap()
> 
>
> Key: TINKERPOP-2059
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2059
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.3
>Reporter: stephen mallette
>    Assignee: Daniel Kuppitz
>Priority: Major
>  Labels: breaking
>
> Allow for modulation of the {{valueMap()}} step with {{by()}} and possibly 
> {{with()}} to make it's usage more flexible and consistent. The problem 
> presented in relation to this change is how to easily unwrap the general 
> multi-property structure of {{valueMap()}}
> {code}
> g.V().has('person','name','marko').
>   valueMap('name','age').
> by(unfold())
> {code}
> which would yield: {{[name:marko,age:29]}} rather than: 
> {{[name:[marko],age:[29]]}}. Obviously the {{by()}} is just a map over the 
> values in the list of values returned from properties. 
> Please see the 
> [DISCUSS|https://lists.apache.org/thread.html/91a3c980b5968c78638383dfa11f44ee14fc114ddc3d29e762e56f1f@%3Cdev.tinkerpop.apache.org%3E]
>  thread for additional thoughts on the matter to consider.



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

[jira] [Closed] (TINKERPOP-2062) Add Traversal class to CoreImports

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2062.
-
   Resolution: Fixed
Fix Version/s: 3.3.5
   3.4.0

> Add Traversal class to CoreImports
> --
>
> Key: TINKERPOP-2062
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2062
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: server
>Affects Versions: 3.3.3
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Minor
> Fix For: 3.4.0, 3.3.5
>
>
> Apparently, some people like to copy Gremlin queries they've written in Java 
> and paste them into the Gremlin console. This should usually work pretty 
> well, however, there are some oddities in particular with {{union()}} step 
> which requires you to cast the child traversals to {{Traversal}} if they have 
> different return types, e.g.:
> {noformat}
> g.V().
> union(
>   __.identity(),
>   (Traversal)__.outE()
> )
> {noformat}
> This works in a local console session but fails if the query is sent to a 
> server as {{Traversal}} is not part of the core imports. 



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

[jira] [Closed] (TINKERPOP-2073) Generate tabs for static code blocks

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz closed TINKERPOP-2073.
-
   Resolution: Fixed
Fix Version/s: 3.3.5

> Generate tabs for static code blocks
> 
>
> Key: TINKERPOP-2073
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2073
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.4.0
>    Reporter: Daniel Kuppitz
>    Assignee: Daniel Kuppitz
>Priority: Major
> Fix For: 3.3.5
>
>
> Tabs are only generated for evaluated code blocks. It should be possible to 
> tabify static code blocks, too.



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

[jira] [Assigned] (TINKERPOP-2059) Modulation of valueMap()

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz reassigned TINKERPOP-2059:
-

Assignee: Daniel Kuppitz

> Modulation of valueMap()
> 
>
> Key: TINKERPOP-2059
> URL: https://issues.apache.org/jira/browse/TINKERPOP-2059
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.3.3
>Reporter: stephen mallette
>    Assignee: Daniel Kuppitz
>Priority: Major
>
> Allow for modulation of the {{valueMap()}} step with {{by()}} and possibly 
> {{with()}} to make it's usage more flexible and consistent. The problem 
> presented in relation to this change is how to easily unwrap the general 
> multi-property structure of {{valueMap()}}
> {code}
> g.V().has('person','name','marko').
>   valueMap('name','age').
> by(unfold())
> {code}
> which would yield: {{[name:marko,age:29]}} rather than: 
> {{[name:[marko],age:[29]]}}. Obviously the {{by()}} is just a map over the 
> values in the list of values returned from properties. 
> Please see the 
> [DISCUSS|https://lists.apache.org/thread.html/91a3c980b5968c78638383dfa11f44ee14fc114ddc3d29e762e56f1f@%3Cdev.tinkerpop.apache.org%3E]
>  thread for additional thoughts on the matter to consider.



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

Development branch cleanup

[Daniel Kuppitz]

The following branches are scheduled for deletion:

TINKERPOP-1342 -- [TINKERPOP-1342] Allow setting scriptEvaluationTimeout in
driver
TINKERPOP-1365 -- [TINKERPOP-1365] Log the seed used to initialize Random
in tests
TINKERPOP-1489 -- [TINKERPOP-1489] Provide a Javascript Gremlin Language
Variant
TINKERPOP-1518 -- [TINKERPOP-1518] Provide a way for providers to expose
static Graph.Features to tests
TINKERPOP-1595 -- [TINKERPOP-1595] Go through TraversalVertexProgram with a
profile and optimize.
TINKERPOP-1656 -- [TINKERPOP-1656] Write-time compilation of mutation steps
TINKERPOP-1730 -- [TINKERPOP-1730] Gremlin .NET support for GraphSON 3.0
TINKERPOP-1738-wip -- [TINKERPOP-1738] Proper functioning of GraphSONReader
depends on order of elements in String representation
TINKERPOP-1744 -- [TINKERPOP-1744] Gremlin .NET: Exception from sync
execution gets wrapped in AggregateException
TINKERPOP-1809 -- [TINKERPOP-1809] Process tests shouldn't modify toy data
TINKERPOP-1820 -- [TINKERPOP-1820] Include .NET GLV tests on TravisCI
TINKERPOP-1827 -- [TINKERPOP-1827] Gremlin .NET: Test Suite Runner
TINKERPOP-1831 -- [TINKERPOP-1831] Refactor EventStrategy
TINKERPOP-1836 -- [TINKERPOP-1836] .NET sample project
TINKERPOP-1837 -- [TINKERPOP-1837] Gremlin .NET: Provide type coercion
between IDictionary instances
TINKERPOP-1841 -- [TINKERPOP-1841] Include Python GLV tests on TravisCI
TINKERPOP-1864 -- [TINKERPOP-1864] Gremlin Python tests for GraphSON 2.0
and 3.0
TINKERPOP-1878 -- [TINKERPOP-1878] Sparql to Gremlin Compiler
TINKERPOP-1880 -- [TINKERPOP-1880] Gremlin.NET Strong name signature could
not be verified. (HRESULT: 0x80131045)
TINKERPOP-1897 -- [TINKERPOP-1897] Provide Docker images of Gremlin Server
and Console
TINKERPOP-1913 -- [TINKERPOP-1913] Expose metadata from Gremlin Server to
Clients
TINKERPOP-1945 -- [TINKERPOP-1945] Add support for extended GraphSon types
to Gremlin.net
TINKERPOP-1958 -- [TINKERPOP-1958] TinkerGraphCountStrategy can return
wrong counts
TINKERPOP-1959 -- [TINKERPOP-1959] Provide a way to submit scripts to the
server in gremlin-javascript
TINKERPOP-1959-master -- [TINKERPOP-1959] Provide a way to submit scripts
to the server in gremlin-javascript
TINKERPOP-1959-tp33 -- [TINKERPOP-1959] Provide a way to submit scripts to
the server in gremlin-javascript
TINKERPOP-1963 -- [TINKERPOP-1963] Use of reducing step in choose()
TINKERPOP-1967 -- [TINKERPOP-1967] Add a connectedComponent() step
TINKERPOP-1968 -- [TINKERPOP-1968] Refactor elements of Gremlin Server
testing
TINKERPOP-1972 -- [TINKERPOP-1972] inject() tests are throwing exceptions
in .NET GLV tests
TINKERPOP-1972-master -- [TINKERPOP-1972] inject() tests are throwing
exceptions in .NET GLV tests
TINKERPOP-1972-tp33 -- [TINKERPOP-1972] inject() tests are throwing
exceptions in .NET GLV tests
TINKERPOP-1975 -- [TINKERPOP-1975] Introduce with() step modulator
TINKERPOP-1975-x -- [TINKERPOP-1975] Introduce with() step modulator
TINKERPOP-1976 -- [TINKERPOP-1976] Include Computer tests for GLVs
TINKERPOP-1978 -- [TINKERPOP-1978] Check for Websocket connection state
when retrieved from Connection Pool missing
TINKERPOP-1979 -- [TINKERPOP-1979] Several OLAP issues in MathStep
TINKERPOP-1985 -- [TINKERPOP-1985] Update position on bulk loading
TINKERPOP-1986 -- [TINKERPOP-1986] Remove deprecation from
PartitionStrategy, SubgraphStrategy and GremlinScriptEngine
TINKERPOP-1987 -- [TINKERPOP-1987] Bump to Netty 4.1.x
TINKERPOP-1989 -- [TINKERPOP-1989] Preserve order that plugins are applied
in Gremlin Console
TINKERPOP-1990 -- [TINKERPOP-1990] Add a shortestPath() step
TINKERPOP-1996 -- [TINKERPOP-1996] Introduce read() and write() steps
TINKERPOP-1999 -- [TINKERPOP-1999] [Java][gremlin-driver] Query to a remote
server via the websocket client hangs indefinitely if the server becomes
unavailable
TINKERPOP-2011 -- [TINKERPOP-2011] Use NumberHelper on choose()
TINKERPOP-2012 -- [TINKERPOP-2012] Target .NET Standard 2.0 for Gremlin.Net
TINKERPOP-2015 -- [TINKERPOP-2015] Allow users to configure the WebSocket
connections
TINKERPOP-2016 -- [TINKERPOP-2016] Upgrade Jackson FasterXML to 2.9.5 or
later to fix security vulnerability
TINKERPOP-2021 -- [TINKERPOP-2021] Prevent maximum recursion depth failure
TINKERPOP-2023 -- [TINKERPOP-2023] Gremlin Server should not create
self-signed certs
TINKERPOP-2024 -- [TINKERPOP-2024] Gremlin Server Application archetype
should connect via withRemote
TINKERPOP-2025 -- [TINKERPOP-2025] Change to SHA-256/512 and drop SHA-1 for
releases
TINKERPOP-2026 -- [TINKERPOP-2026] Gremlin.Net.Driver should check
ClientWebSocket.State before closing
TINKERPOP-2029 -- [TINKERPOP-2029] ConcurrentModificationException for
InlineFilterStrategy
TINKERPOP-2029-master -- [TINKERPOP-2029] ConcurrentModificationException
for InlineFilterStrategy
TINKERPOP-2030 -- [TINKERPOP-2030] KeepAlive task executed for every
Connection.write call
TINKERPOP-2031 -- [TINKERPOP-2031] Remove support for -i in
gremlin-server.sh
TINKERPOP-2032 -- [TINKE