[
https://issues.apache.org/jira/browse/TINKERPOP3-971?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034941#comment-15034941
]
Marko A. Rodriguez edited comment on TINKERPOP3-971 at 12/2/15 12:31 AM:
-------------------------------------------------------------------------
I think we can get rid of {{TraversalEngine}}. We basically just have:
{code}
Optional<GraphComputer> Traversal.Admin.getComputer();
{code}
Then this stuff:
{code}
if (traversal.getEngine().isComputer()) { ... }
{code}
simply becomes:
{code}
if(traversal.getComputer().isPresent()) { ... }
{code}
What is nice is that a {{ReasoningStrategy}} (for example) which determines
whether to execute OLAP or OLTP, would simply {{traversal.setComputer(null)}}
if it believes the traversal should be executed OLTP. Likewise, the
{{ReasoningStrategy}} can augment the {{GraphComputer}} on the fly via:
{code}
// ReasoningStrategy
if(simpleButOLAP) {
traversal.setComputer(traversal.getComputer().get().workers(1));
} else if(superSuperSimpleThusOLTP) {
traversal.setComputer(null);
}
// and check this out with our new computer.vertices().edges() filters in 3.2.0
traversal.setComputer(traversal.getComputer().vertices(hasLabel("person")).edges(hasLabel("knows"));
// BAM!!!!!!!!!!!!!!!!!!!!!!!!
{code}
Thus, there is no {{ReasoningEngine}} ({{TraversalEngine}} goes away).
Likewise, there is no {{GremlinServerEngine}}. For Gremlin Server execution,
you could do:
{code}
g =
graph.traversal().withStrategy(GremlinServerStrategy.build().ip(127.0.0.2).port(134).create())
{code}
Then you no longer need all this nasty infrastructure:
https://issues.apache.org/jira/browse/TINKERPOP3-575. Instead,
{{GremlinServerStrategy}} would simply append a {{GremlinServerResultStep}} at
the end of the {{Traversal}} EXACTLY how {{ComputerResultStep}} is appended for
graph computer execution.
To make this crystal clear, we could remove {{TraversalSource.compute()}} and
have it be this:
{code}
g = graph.traversal().withStrategy(ComputerStrategy.build().compute(graph ->
graph.compute(Spark).workers(10)).attachElements(false)).create())
{code}
In essence, {{graph.traversal().compute(Function<Graph,GraphComputer>)}} is
shorthand for the above. As it is right now {{ComputerStrategy}} simply adds a
{{ComputerResultStep}} to the end of the {{Traversal}} (as a {{Finalization}}).
However, with this model, it would need to be a {{Decoration}}.
We could have a shorthand be:
{code}
g = graph.traversal().withStrategy(ComputerStrategy.using(SparkGraphComputer))
{code}
Or, using the default {{GraphComputer}} of the {{Graph}}
{code}
g = graph.traversal().withStrategy(ComputerStrategy.instance())
{code}
Ah... the plot thickens. Then this whole {{Traversal.Admin.getComputer()}}
stuff can simply be this:
{code}
public Optional<GraphComputer> getComputer() {
if(this.strategies.toList().contains(ComputerStrategy))
return strategies.toList().get(ComputerStrategy).getComputer()
}
{code}
That is some crazy talk but its genious in that EVERYTHING is a
{{TraversalStrategy}}. Nothing is "special" -- no engines, no computers. Its
all via strategies.
was (Author: okram):
I think we can get rid of {{TraversalEngine}}. We basically just have:
{code}
Optional<GraphComputer> Traversal.Admin.getComputer();
{code}
Then this stuff:
{code}
if (traversal.getEngine().isComputer()) { ... }
{code}
simply becomes:
{code}
if(traversal.getComputer().isPresent()) { ... }
{code}
What is nice is that a {{ReasoningStrategy}} (for example) which determines
whether to execute OLAP or OLTP, would simply {{traversal.setComputer(null)}}
if it believes the traversal should be executed OLTP. Likewise, the
{{ReasoningStrategy}} can augment the {{GraphComputer}} on the fly via:
{code}
// ReasoningStrategy
if(simpleButOLAP) {
traversal.setComputer(traversal.getComputer().get().workers(1));
} else if(superSuperSimpleThusOLTP) {
traversal.setComputer(null);
}
{code}
Thus, there is no {{ReasoningEngine}} ({{TraversalEngine}} goes away).
Likewise, there is no {{GremlinServerEngine}}. For Gremlin Server execution,
you could do:
{code}
g =
graph.traversal().withStrategy(GremlinServerStrategy.build().ip(127.0.0.2).port(134).create())
{code}
Then you no longer need all this nasty infrastructure:
https://issues.apache.org/jira/browse/TINKERPOP3-575. Instead,
{{GremlinServerStrategy}} would simply append a {{GremlinServerResultStep}} at
the end of the {{Traversal}} EXACTLY how {{ComputerResultStep}} is appended for
graph computer execution.
To make this crystal clear, we could remove {{TraversalSource.compute()}} and
have it be this:
{code}
g = graph.traversal().withStrategy(ComputerStrategy.build().compute(graph ->
graph.compute(Spark).workers(10)).attachElements(false)).create())
{code}
In essence, {{graph.traversal().compute(Function<Graph,GraphComputer>)}} is
shorthand for the above. As it is right now {{ComputerStrategy}} simply adds a
{{ComputerResultStep}} to the end of the {{Traversal}} (as a {{Finalization}}).
However, with this model, it would need to be a {{Decoration}}.
We could have a shorthand be:
{code}
g = graph.traversal().withStrategy(ComputerStrategy.using(SparkGraphComputer))
{code}
Or, using the default {{GraphComputer}} of the {{Graph}}
{code}
g = graph.traversal().withStrategy(ComputerStrategy.instance())
{code}
Ah... the plot thickens. Then this whole {{Traversal.Admin.getComputer()}}
stuff can simply be this:
{code}
public Optional<GraphComputer> getComputer() {
if(this.strategies.toList().contains(ComputerStrategy))
return strategies.toList().get(ComputerStrategy).getComputer()
}
{code}
That is some crazy talk but its genious in that EVERYTHING is a
{{TraversalStrategy}}. Nothing is "special" -- no engines, no computers. Its
all via strategies.
> 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
> 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)
