We currently have 17 @IgnoreEngine annotations left, everything else is
either working in OLAP or caught by the ComputerVerificationStrategy. These
are the remaining test cases that do currently not work in OLAP and that
have no pattern that is recognized by the ComputerVerificationStrategy:
-
*SideEffectTest (2): *
- g.withSideEffect("a", ArrayList::new).V(v1Id).sideEffect(traverser
-> {
traverser.<List>sideEffects("a").clear();
traverser.<List<Vertex>>sideEffects("a").add(traverser.get());
}).values("name")
- g.withSideEffect("c", () -> {
final List<Integer> list = new ArrayList<>();
list.add(0);
return list;
}).V(v1Id).out().sideEffect(traverser -> {
Integer temp =
traverser.<List<Integer>>sideEffects("c").get(0);
traverser.<List<Integer>>sideEffects("c").clear();
traverser.<List<Integer>>sideEffects("c").add(temp +
1);
}).values("name")
Apparently the problem is .withSideEffect(), which is not a step and thus
can not easily be recognized by the strategy.
- *ProfileTest (2):*
To make it short: I don't think we need .profile() in OLAP.
- *SampleTest (2):*
GlobalSampleStep should be allowed as the last step in an OLAP traversal
(same as OrderGlobalStep). However, the implementation doesn't seem to be
straightforward as ordering is sort of a first class citizen in MapReduce,
but sampling/filtering is not.
- *WhereTest (2):*
-
g.V().has("age").as("a").out().in().has("age").as("b").select().where(as("b").has("name",
"marko"))
-
g.V().has("age").as("a").out().in().has("age").as("b").select().where(as("a").out("knows").as("b"))
The classic old problem: how much information is available in a path? We
should be able to make those queries work (the latter should be really
easy, I wonder why it doesn't work already).
- *MapTest (2):*
- g.withPath().V().as("a").out().<String>map(v ->
v.<Vertex>path("a").value("name"))
- g.withPath().V().as("a").out().out().map(v ->
v.<Vertex>path("a").<String>value("name") + v.get().<String>value("name"))
This is the hardest and most general problem: lambdas. Well, maybe it's the
easiest? Lambda -> do not allow in OLAP? .... Nah, that would be really bad.
- *OrderTest (5):*
- g.V().<String>values("name").order().by((a, b) -> a.substring(1,
2).compareTo(b.substring(1, 2))).by((a, b) -> b.substring(2,
3).compareTo(a.substring(2, 3)))
Again lambdas seem to be the problem, though we don't have any
invalid element- or property-access. Should work.
- g.V().order().by("name", Order.incr).values("name")
The mid-traversal OrderGlobalStep could also be the end step (a smart
strategy could modify the traversal accordingly***).
- g.V().outE().order().by("weight", Order.decr).values("weight")
The mid-traversal OrderGlobalStep could also be the end step (a smart
strategy could modify the traversal accordingly***).
- g.V().order().<String>by("name", (a, b) -> a.substring(1,
2).compareTo(b.substring(1, 2))).
<String>by("name", (a, b) -> b.substring(2,
3).compareTo(a.substring(2, 3))).values("name")
This one is too complex. order.by(lambda) followed by a property
access. Since we do not know what's done within the lambda, we
cannot make
OrderGlobalStep the end step, hence this pattern should not be
allowed.
- g.V().order().by(outE().count(), Order.decr)
I'm totally unsure about this one.
- *SubgraphStrategyProcessTest (2):*
I can't comment on this one as I'm not familiar with the SubgraphStrategy
implementation.
*** This is probably already done, I didn't check the test results again.
We also have 2 ClassCastExceptions in OrderTest - chances are high that the
CCEs occur in these 2 test cases.
Cheers,
Daniel
