Marko A. Rodriguez created TINKERPOP3-971:
---------------------------------------------
Summary: TraversalSource should be fluent like GraphComputer
Key: TINKERPOP3-971
URL: https://issues.apache.org/jira/browse/TINKERPOP3-971
Project: TinkerPop 3
Issue Type: Improvement
Components: process
Affects Versions: 3.1.0-incubating
Reporter: Marko A. Rodriguez
Assignee: Marko A. Rodriguez
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)
