[
https://issues.apache.org/jira/browse/TINKERPOP3-774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632549#comment-14632549
]
Marko A. Rodriguez commented on TINKERPOP3-774:
-----------------------------------------------
Excellent. And, yes, we should call it {{FilterBijectionStrategy}}. I always
thought of this strategy being "what can I put after dedup?," but as you
realized, its more about what can after a filter. However, what is it that
{{FilterSteps}} can "rotate around?" They can only go around bijective steps
like {{OrderStep}}. They can't go around {{AggregateStep}} cause of
sideEffects. What is the general concept behind {{OrderStep}}?
1. It doesn't add more data to the stream.
2. It doesn't yield any sideEffect behaviors.
3. It is expensive to execute (both time and space).
So, {{FilterBijectionStrategy}} could take any {{FilterStep}} and place it in
front of a step of that nature. What steps are like that?
1. {{OrderGlobalStep}}
2. ??{{SampleGlobalStep}}
3. huh..... thats all I can think of. ??..
{code}
order().has() => has().order()
order().dedup() => dedup().order()
order().filter(out()) => filter(out()).order() // what is cheaper? :)
order().filter{it...} => filter{it...}.order() // not smart cause a lambda
could have a sideEffect.
order().is(pred) => is(pred).order()
order().where(pred) => where(pred).order()
order().where(traversal) => where(traversal).order() // what is cheaper?
order().simplePath() => simplePath().order()
{code}
I think the we have to have a {{private static Set<Class<Step>>}} member in
{{FilterBijectionStrategy}} that lists each legal step class as {{FilterStep}}
isn't safe (e.g. {{DropStep}}, {{AndStep}}?, {{TimeLimitStep}}?, {{CoinStep}},
{{RangeGlobalStep}}, ...).
....................huh, some filters are more expensive than others!
{code}
filter(traversal).and(traversal,traversal).has() =>
has().filter(traversal).and(traversal,traversal)
{code}
Its like {{FilterBijectionStrategy}} should simply reorder filters according to
a ranking where {{order()}} is in the mix as an "identity filter" and last in
the list!!
Perhaps: {{FilterRankingStrategy}}
> order / dedup issues
> --------------------
>
> Key: TINKERPOP3-774
> URL: https://issues.apache.org/jira/browse/TINKERPOP3-774
> Project: TinkerPop 3
> Issue Type: Bug
> Components: process
> Affects Versions: 3.0.0-incubating
> Reporter: Daniel Kuppitz
> Assignee: Daniel Kuppitz
>
> Not sure if this is an {{order}}- or a {{dedup}}-issue (or maybe both), but
> these two steps don't play well together. The following sample were created
> using the GD graph.
> *{{dedup()}} w/o keys*
> {code}
> g.V().as("a").outE("followedBy").as("e").inV().as("b").
> select("e").order().by("weight", decr).limit(10).
> select("b").out("sungBy").dedup()
>
> ==>v[453]
> ==>v[347]
> ==>v[405]
> ==>v[342]
> ==>v[342]
> ==>v[340]
> ==>v[342]
> ==>v[351]
> ==>v[351]
> {code}
> *{{dedup()}} w/ keys*
> {code}
> g.V().as("a").outE().as("e").inV().as("b").
> select("e").order().by("weight", decr).limit(10).
> as("c").inV().as("d").dedup("c","d")
>
> Neither the sideEffects, map, nor path has a c-key: DedupGlobalStep([c, d])
> Display stack trace? [yN]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
