[
https://issues.apache.org/jira/browse/TINKERPOP-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142677#comment-15142677
]
ASF GitHub Bot commented on TINKERPOP-971:
------------------------------------------
Github user okram commented on the pull request:
https://github.com/apache/incubator-tinkerpop/pull/215#issuecomment-182853040
A response to each item in your list.
* This will go away when TINKERPOP-1140 is complete. This is a "staging
method" for now.
* This is not a critical performance line of code. This is during
`TraversalSource` construction which is like saying "a database connection
creation method uses stream."
* Same as previous.
* Same as previous -- submitting a `GraphComputer` job is crazy costly
relative to this simple `stream()`.
* This will go away when TINKERPOP-1140 is complete. This is a "staging
method" for now.
* This is test suite setup code. Performance doesn't matter.
* Same as previous.
To your "old code" reference:
* Yes, we should not use `stream()` here. This class needs to be blazing
fast. I believe you and I are the author of this class and we should fix it.
That is for another ticket.
NOTE: We should also remove all the `stream()` work in `StarGraph` (there
is a butt load).
> TraversalSource should be fluent like GraphComputer
> ---------------------------------------------------
>
> Key: TINKERPOP-971
> URL: https://issues.apache.org/jira/browse/TINKERPOP-971
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.0-incubating
> Reporter: Marko A. Rodriguez
> Assignee: Marko A. Rodriguez
> Labels: breaking
> Fix For: 3.2.0-incubating
>
>
> I just realized something so obvious. {{TraversalSource}} should be fluent
> and not this awkward {{TraversalSource.Builder}} model we use. You should be
> able to do this:
> {code}
> graph = GraphFactory.open(...)
> g = graph.traversal()
> g = g.withStrategy(MyStrategy.class)
> g = g.withSack(1.0,sum)
> ...
> g.V().out().sack()
> g.V().out().out().drop()
> {code}
> Thus, {{TraversalSource}} methods return a {{TraversalSource}}.
> {code}
> g =
> graph.traversal(computer(GiraphGraphComputer)).withStrategy(MyStrategy.class).withSack(1.0,sum).withBulk(false)
> {code}
> That {{g}} is then "locked" with those parameterizations and any
> {{V()}}/{{addV()}}/etc. off of it will spawn traversal with that
> parameterization.
> This solves:
> TINKERPOP3-862
> TINKERPOP3-960 (makes more elegant)
> This would be backwards compatible. Though, deprecation would occur.
> Finally, DSLs are still respected.
> {code}
> g = graph.traversal(SocialTraversal.class)
> {code}
> A fleeting thought...
> {code}
> g = graph.traversal().using(GiraphGraphComputer)
> g = graph.traversal().via(GremlinServerConnection).using(GiraphGraphComputer)
> {code}
> So much cleaner than all that {{Builder}}-crap....
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
