[jira] [Created] (TINKERPOP-1372) ImmutablePath should not use Java recursion (call stacks are wack)

[Marko A. Rodriguez (JIRA)]

Marko A. Rodriguez created TINKERPOP-1372:
-

 Summary: ImmutablePath should not use Java recursion (call stacks 
are wack)
 Key: TINKERPOP-1372
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1372
 Project: TinkerPop
  Issue Type: Improvement
  Components: process
Affects Versions: 3.2.0-incubating
Reporter: Marko A. Rodriguez


{{ImmutablePath}} sucks for a few reasons:

1. It has {{ImmutablePathImpl}} interface to combine {{Tail}} and 
{{ImmutablePath}}. Lame.
2. It uses recurssion to find data. Lame.

For 3.2.1, I have done a lot to use {{while()}}-based recursion and I suspect I 
can gut {{ImmutablePathImpl}} and few other kooky things.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop pull request #360: revise a mutable default kwarg on GraphTraversa...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/tinkerpop/pull/360


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: Documentation deprecation warning on Github Wikis

[Jean-Baptiste Musso]

Done - I just updated all Wiki pages on the tinkerpop/blueprints
Github repository.

Jean-Baptiste

On Tue, Jul 12, 2016 at 1:44 AM, Jason Plurad  wrote:
> +1
>
> Could you also update these? I've fielded lots of questions referring to
> these old graph I/O pages.
>
> https://github.com/tinkerpop/blueprints/wiki/GraphSON-Reader-and-Writer-Library
>
> https://github.com/tinkerpop/blueprints/wiki/GraphML-Reader-and-Writer-Library
>
> https://github.com/tinkerpop/blueprints/wiki/GML-Reader-and-Writer-Library
>
> https://github.com/tinkerpop/blueprints/wiki/Batch-Implementation
>
> Thanks!
> -- Jason
> On Mon, Jul 11, 2016 at 6:36 PM Jean-Baptiste Musso 
> wrote:
>
>> Quick follow up - the changes to the TP2 Gremlin documentation are now
>> live. Props to Dylan since I couldn't remember where this was first
>> mentioned.
>>
>> See for example
>> https://github.com/tinkerpop/gremlin/wiki/Depth-First-vs.-Breadth-First
>>
>> Editing several pages on GitHub wikis was indeed as simple as cloning
>> the wiki repository and doing commits (git clone
>> https://github.com/tinkerpop/gremlin.wiki). Anything that hits the
>> master branch goes live once pushed to Github.
>>
>> Jean-Baptiste
>>
>> On Wed, Jun 8, 2016 at 2:20 PM, Stephen Mallette 
>> wrote:
>> > Jean-Baptiste, +1 for the wiki changes - and thanks for volunteering.
>> I've
>> > given you access to all the old repos in github so you should be free to
>> > make the changes. Maybe give this thread another day to make sure no
>> other
>> > comments trickle in before you go to work on the changes. I think we
>> might
>> > want to go the extra step of adding your header to the READMEs and
>> replace
>> > our current gremlinbusters image - that way everything is consistent.
>> >
>> > Dylan, the gremlin-users info was very out of date, so I updated the
>> About
>> > description:
>> >
>> > https://groups.google.com/forum/#!aboutgroup/gremlin-users
>> >
>> > and included a welcome message that points to the latest docs/website:
>> >
>> > https://groups.google.com/forum/#!forum/gremlin-users
>> >
>> > Everyone good with those changes?
>> >
>> >
>> >
>> > On Tue, Jun 7, 2016 at 4:54 PM, Dylan Bethune-Waddell <
>> > dylan.bethune.wadd...@mail.utoronto.ca> wrote:
>> >
>> >> I believe I mentioned this on the Titan or Tinkerpop mailing list but it
>> >> was off-topic at the time, so I will restate here:
>> >>
>> >>
>> >> What about a pinned post on the gremlin-users mailing lists linking to
>> the
>> >> most recent docs and website as another guidepost for users in line with
>> >> this one? Does this edit to all the old wikis etc. make such a thing
>> >> redundant? My thinking on this is that it would be similar to the pinned
>> >> post titled "On proper issue submission" at the top of the Titan mailing
>> >> list - short and sweet, saving Tinker-time solving problems on the list
>> >> that are not easily reproducible or particularly
>> relevant/straightforward.
>> >> It could also prevent some posts based on outdated information that
>> beget
>> >> more relevant questions posted deep down in the thread, which now has a
>> >> misleading title that does not match the core of its content.
>> >>
>> >> 
>> >> From: Jean-Baptiste Musso 
>> >> Sent: Tuesday, June 7, 2016 4:05:16 PM
>> >> To: dev@tinkerpop.apache.org
>> >> Subject: Documentation deprecation warning on Github Wikis
>> >>
>> >> Dear devs,
>> >>
>> >> I was thinking recently that we could add a deprecation warning
>> >> message on top of all former Github Wiki pages and warn visitors that
>> >> a new version of TinkerPop is available. I think this was also brought
>> >> up recently on the mailing list so I'm opening a discussion here.
>> >>
>> >> I feel that some newcomers are still hitting old school TinkerPop 2
>> >> material when google'ing for graphs, Gremlin and TinkerPop. Adding a
>> >> warning message on top of old Wiki pages pointing them to the freshest
>> >> development on the Apache TinkerPop website could certainly help.
>> >>
>> >> If everyone agrees, I'm volunteering to git clone the Wiki on all
>> >> repositories and edit all pages. As Stephen noted on HipChat, it's as
>> >> simple as following these steps:
>> >> https://help.github.com/articles/adding-and-editing-wiki-pages-locally/
>> >> Adding and editing wiki pages locally - User Documentation<
>> >> https://help.github.com/articles/adding-and-editing-wiki-pages-locally/
>> >
>> >> help.github.com
>> >> Cloning wikis locally to your computer. Every wiki provides an easy way
>> to
>> >> clone its contents down to your computer: If you're using GitHub
>> Desktop,
>> >> click Clone in ...
>> >>
>> >>
>> >>
>> >>
>> >> Here's an example of such header we could add:
>> >>
>> >> https://gist.github.com/jbmusso/802cf97ceb20547ba6abf0b4112ac3ee
>> >>
>> >> Thoughts? Feel free to iterate. The wording could be improved.
>> >>
>> >> Cheers,
>> >>
>> 

PathRetractionStrategy -- Ted Wilmes work coming to TinkerPop 3.2.1

[Marko Rodriguez]

Hello,

I believe that the most important aspect of Gremlin is the concept of bulking. 
With graph traversals leading to combinatoric explosions in both time and 
space, the best way to battle such explosions is to realize that even if the 
number of unique paths is increasing rapidly, there is an upper limit on the 
number of unique vertices touched. In order to project an exponential space to 
a constant space, Gremlin traverses have the concept of a bulk. If two 
traversers “are equals,” then when they meet each other at the same step in the 
traversal and location in the graph, they are merged and their respective bulks 
are sum’d. Thus, two traverser become one. Excellent. This is why we can do 
massive branch traversals like below in blazing fast time:

gremlin> clockWithResult(10){g.V().repeat(out()).times(10).count().next()}
==>32.8619489 // 33 milliseconds
==>4947356572210703772 // 4 quintillion paths explored

However, this model breaks down when traversers are no longer “equal.” While 
two traversers may have the same step and graph location, they may have 
different path histories. Thus, for traversals that leverage path information, 
it is very difficult to get traverser equality and thus, because the number of 
unique paths grows exponentially and traverser equality is determined by path 
equality (when paths are required for a traversal), you get exponential 
traverser growth.

gremlin> 
clockWithResult(10){g.V().repeat(out()).times(10).path().count().next()}
// this will not complete within the life of universe

Thus, in order to make Gremlin fast, its all about doing our best to reduce the 
amount of information each traverser maintains which, in principle, increases 
the likelihood that any two traversers can be merged/bulked (increases the 
likelihood of “equality”).

Ted Wilmes led the development of 
https://issues.apache.org/jira/browse/TINKERPOP-1254 
. With this ticket, 
traversers are able to shed path information they will no longer need down the 
line. Thus, not only reducing their path footprint (space), but also increasing 
the likelihood of bulking (space+time). How does it work? Take the following 
example traversal:

g.V().as(‘a’).out().as(‘b’).where(‘a’,eq(‘b’)).select(‘a’).out() // get the 
adjacent neighbors of those traversers that have themselves as a neighbor

Prior to PathRetractionStrategy, a traverser’s path history would look like 
this:

[v[1]]  // V
[v[1], v[2]]// out
[v[1], v[2]]// where
[v[1], v[2], v[1]]  // select
[v[1], v[2], v[1], v[3]]// out

Now with PathRetractionStrategy.

[v[1]]  // V
[v[1], v[2]]// out
[v[1]]  // where
[]  // select
[]  // out

Once where() is done with “b”, it wipes the “b”-path information for the 
traverser’s path history. Next, once select() is done with “a”, it wipes 
“a”-path information from the traverser’s path history. Thus, after select(), 
there is no longer path information required for the traversal to faithfully 
execute. Moreover, after select(), bulking becomes extremely likely and thus, 
instead of calculating out() on an exponential set of traversers, we will only 
calculate it on the upper limit of traverses which is |V| (the total number of 
vertices in the graph). Next, what is really cool is that MatchStep is smart 
about pruning path information dynamically as needed based upon which patterns 
still required for the traverser to complete its computation. Here is a 
match()-traversal that finds all vertices that are in a triangle relationship. 
Note that we don’t care about triangles, just the vertices involved in one as 
we only select(“a”). However, by only selecting(“a”) this means that MatchStep 
is able to dynamically prune path information as it is no longer needed — “b” 
and “c".

g.V().has(“performances”,gt(500)).match(
  as("a").out().as("b"),
  as(“b”).out().as("c”),
  as(“c”).out().as(“a”)).select("a").profile()


This leads to the following runtimes below. Notice how PathRetractionStrategy 
is able to increase the likelihood of bulking in MatchStep — as path 
information is shed (no longer needed for the remaining patterns to check), 
traversers get merged and thus, less computation is required. However, if you 
need to select(“a”,”b”,”c”) from the match() patterns, well, then 
PathRetractionStrategy provides no benefit. Though, if you just need “a” and 
“b”, then PathRetractionStrategy helps. In short, as long as intermediate 
results can be shed along the way, then PathRetractionStrategy will capitalize 
on this fact and increase the likelihood of bulking.

OLTP w/o PathRetractionStrategy 

Traversal Metrics
Step   Count  
Traversers   Time (ms)% Dur

[jira] [Commented] (TINKERPOP-1367) Preserve path history for min() and max()

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1367:
---

I provided a lambda-free traversal on the mailing list, that does exactly that 
(emit all max paths). We can make it work with what we currently have, but it's 
pretty cumbersome (and memory intensive). Two separate queries would probably 
perform better than the single all-in-one query. Hence, I like the min/max 
sideEffect proposal. Kinda... It still doesn't look very intuitive, but much 
better than what we can currently do.

> Preserve path history for min() and max()
> -
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Jason Plurad
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.). 
> But they are indeed different when it comes to path computations. Some of 
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this 
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be 
> some sort of "barrier" FilterStep.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TINKERPOP-1369) Replace REST API with HTTP API

[Robert Dale (JIRA)]

Robert Dale created TINKERPOP-1369:
--

 Summary: Replace REST API with HTTP API
 Key: TINKERPOP-1369
 URL: https://issues.apache.org/jira/browse/TINKERPOP-1369
 Project: TinkerPop
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.2.1
Reporter: Robert Dale
Priority: Minor


The "REST API" follows exactly none of the tenets of being RESTful.  Suggest 
renaming it to HTTP API so as to not mislead developers as to the design of the 
API.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1367) Preserve path history for min() and max()

[Marko A. Rodriguez (JIRA)]

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

Marko A. Rodriguez commented on TINKERPOP-1367:
---

Oh. Well, in that case, that is not a reducing barrier step... You need to find 
ALL max paths. hmmm... 

So there are two 1.0 weight values in the Modern graph.

{code}
gremlin> g.V().outE().values('weight').order().by(decr).limit(2).path()
==>[v[1], e[8][1-knows->4], 1.0]
==>[v[4], e[10][4-created->5], 1.0]
{code}

I don't even know how to express this easily without two traversals...

{code}
gremlin> 
g.V().outE().values('weight').max().as('a').V().outE().values('weight').where(eq('a')).path()
==>[1.0, v[1], e[8][1-knows->4], 1.0]
==>[1.0, v[4], e[10][4-created->5], 1.0]
{code}

Ah...we could do something like {{MaxSideEffectStep}} analogous to 
{{GroupCountStep}} and {{GroupCountSideEffectStep}}. THE BELOW DOESN'T EXIST, 
BUT DEMONSTRATES THE IDEA:

{code}
gremlin> g.V().outE().values('weight').max('a').barrier().where(eq('a')).path()
==>[1.0, v[1], e[8][1-knows->4], 1.0]
==>[1.0, v[4], e[10][4-created->5], 1.0]
{code}

The above can currently be done using {{sideEffect}}-step. THE BELOW DOES EXIST.

{code}
gremlin> g.withSideEffect('a',0).V().outE().values('weight').sideEffect{t -> 
if(t.get() > t.sideEffects('a')) 
t.sideEffects('a',t.get())}.barrier().where(eq('a')).path()
==>[v[1], e[8][1-knows->4], 1.0]
==>[v[4], e[10][4-created->5], 1.0]
{code}

Thus, you store the max value into the side-effect {{a}}. You {{barrier()}} so 
you aggregate it all to get the true max (as opposed to a running max) and then 
you drain the barrier and filter those values that aren't the max {{a}}. The 
problem here is the {{barrier}} which makes this NOT a lazy traversal and thus, 
lots of memory consumption (especially with path calculations turned on). In 
this respects, we are back to the {{order().limit()}}-pattern which is also 
memory intensive (unless we get {{OrderLimitStrategy}} to work with OLTP).

> Preserve path history for min() and max()
> -
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Jason Plurad
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.). 
> But they are indeed different when it comes to path computations. Some of 
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this 
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be 
> some sort of "barrier" FilterStep.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1367) Preserve path history for min() and max()

[Jason Plurad (JIRA)]

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

Jason Plurad commented on TINKERPOP-1367:
-

Right, from the original post on the mailing list, we were trying to get all 
paths that had a property that matched the max value.

> Preserve path history for min() and max()
> -
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Jason Plurad
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.). 
> But they are indeed different when it comes to path computations. Some of 
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this 
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be 
> some sort of "barrier" FilterStep.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TINKERPOP-1274) GraphSON Version 2.0

[ASF GitHub Bot (JIRA)]

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

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

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Adding my email on dev@ to here.

I’m not following this PR too closely so what I might be saying is a 
already known/argued against/etc.

1. I think we should go with @robertdale proposal of int32, int64, 
Vertex, uuid, etc. instead of Java class names.
2. In Java we then have a `Map` for typecasting 
accordingly.
3. This would make GraphSON 2.0 perfect for Bytecode serialization in 
TINKERPOP-1278.
4. I think that if a Vertex, Edge, etc. doesn’t have properties, outV, 
etc. then don’t even have those fields in the representation.
5. Most of the serialization back and forth will be `ReferenceXXX` 
elements and thus, don’t create more Maps/lists for no reason. — less chars.

For me, my interests with this work is all about a language agnostic way of 
sending Gremlin traversal bytecode between different languages. This work is 
exactly what I am looking for.


> GraphSON Version 2.0
> 
>
> Key: TINKERPOP-1274
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1274
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: io
>Affects Versions: 3.1.2-incubating
>Reporter: stephen mallette
>Priority: Minor
> Fix For: 3.2.1
>
>
> Develop a revised version of GraphSON that provides better support for 
> non-JVM languages that consume it. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] tinkerpop issue #351: TINKERPOP-1274: GraphSON 2.0.

[okram]

Github user okram commented on the issue:

https://github.com/apache/tinkerpop/pull/351
  
Adding my email on dev@ to here.

I’m not following this PR too closely so what I might be saying is a 
already known/argued against/etc.

1. I think we should go with @robertdale proposal of int32, int64, 
Vertex, uuid, etc. instead of Java class names.
2. In Java we then have a `Map` for typecasting 
accordingly.
3. This would make GraphSON 2.0 perfect for Bytecode serialization in 
TINKERPOP-1278.
4. I think that if a Vertex, Edge, etc. doesn’t have properties, 
outV, etc. then don’t even have those fields in the representation.
5. Most of the serialization back and forth will be `ReferenceXXX` 
elements and thus, don’t create more Maps/lists for no reason. — less chars.

For me, my interests with this work is all about a language agnostic way of 
sending Gremlin traversal bytecode between different languages. This work is 
exactly what I am looking for.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: [DISCUSS] New IO format for GLVs/Gremlin Server

[Marko Rodriguez]

Hi,

I’m not following this PR too closely so what I might be saying is a already 
known/argued against/etc.

1. I think we should go with Robert Dale’s proposal of int32, int64, 
Vertex, uuid, etc. instead of Java class names.
2. In Java we then have a Map for typecasting accordingly.
3. This would make GraphSON 2.0 perfect for Bytecode serialization in 
TINKERPOP-1278.
4. I think that if a Vertex, Edge, etc. doesn’t have properties, outV, 
etc. then don’t even have those fields in the representation.
5. Most of the serialization back and forth will be ReferenceXXX 
elements and thus, don’t create more Maps/lists for no reason. — less chars.

For me, my interests with this work is all about a language agnostic way of 
sending Gremlin traversal bytecode between different languages. This work is 
exactly what I am looking for.

Thanks,
Marko.

http://markorodriguez.com



> On Jul 9, 2016, at 9:48 AM, Stephen Mallette  wrote:
> 
> With all the work on GLVs and the recent work on GraphSON 2.0, I think it's
> important that we have a solid, efficient, programming language neutral,
> lossless serialization format. Right now that format is GraphSON and it
> works for that purpose (ever more  so with 2.0). Given some discussion on
> the GraphSON 2.0 PR driven a bit by Robert Dale:
> 
> https://github.com/apache/tinkerpop/pull/351#issuecomment-231157389
> 
> I wonder if we shouldn't consider another IO format that has Gremlin
> Server/GLVs in mind. At this point I'm not suggesting anything specific -
> I'm just hanging the idea out for further discussion and brain storming.
> Thoughts?

Re: [DISCUSS] Community Survey

[Stephen Mallette]

> It might be a good chance to reflect and get some feedback on how the
TinkerPop community is shaping up with a survey.

Jason, I think you need to elaborate here. Get feedback from who? Do you
literally mean the "community" or the software project or something else?
Do other open source projects do this that you are aware of?

> Also it would be great if we can get some more folks in the community to star
the Apache TinkerPop

Agreed - no idea how to do that - hell, people still star the old ones.



On Mon, Jul 11, 2016 at 11:06 AM, Jason Plurad  wrote:

> We're about at the 1 year anniversary of the Apache TinkerPop 3.0.0
> release. It might be a good chance to reflect and get some feedback on how
> the TinkerPop community is shaping up with a survey. I've never done
> anything like this before, so I don't know if email is good enough or if we
> should use something like a Google Form or Survey Monkey.
>
> Also it would be great if we can get some more folks in the community to
> star the Apache TinkerPop  repo
> mirror in GitHub. It's still well behind the old Blueprints/Gremlin repos.
>
> Thoughts?
>
> -- Jason
>

[jira] [Commented] (TINKERPOP-1367) Preserve path history for min() and max()

[Daniel Kuppitz (JIRA)]

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

Daniel Kuppitz commented on TINKERPOP-1367:
---

{quote}
I was thinking more on this during my evening walk and thought – if there are 
"ties" in {{max()}} and {{min()}}, which path survives?
{quote}

I would say any path, as long as it crosses the/a min/max value. It's actually 
the same as with {{dedup()}}.

> Preserve path history for min() and max()
> -
>
> Key: TINKERPOP-1367
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1367
> Project: TinkerPop
>  Issue Type: Improvement
>  Components: process
>Affects Versions: 3.2.0-incubating
>Reporter: Jason Plurad
>
> Via https://groups.google.com/d/msg/gremlin-users/qZwsvRjw7L4/YyT-s1foBAAJ
> {noformat}
> gremlin> g.V().outE().as('e').values('weight').path()
> ==>[v[1], e[9][1-created->3], 0.4]
> ==>[v[1], e[7][1-knows->2], 0.5]
> ==>[v[1], e[8][1-knows->4], 1.0]
> ==>[v[4], e[10][4-created->5], 1.0]
> ==>[v[4], e[11][4-created->3], 0.4]
> ==>[v[6], e[12][6-created->3], 0.2]
> gremlin> g.V().outE().as('e').values('weight').max().path()
> ==>[1.0]
> {noformat}
> Currently all reducing barriers are treated the same (min, max, mean, etc.). 
> But they are indeed different when it comes to path computations. Some of 
> them could preserve the path history, others could not.
> For max() and min(), we could preserve the path history. In fact, in this 
> respect, max() and min() would NOT be ReducingBarrierSteps, but in fact be 
> some sort of "barrier" FilterStep.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)