[
https://issues.apache.org/jira/browse/TINKERPOP-1212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marko A. Rodriguez closed TINKERPOP-1212.
-----------------------------------------
Resolution: Invalid
Assignee: Marko A. Rodriguez
Please see {{ProjectStep}}.
{code}
g.V().
project("a","b").
by().
by(inE().count()).
order().
by(select("b"),decr).
limit(10).
select("a","b").
by(valueMap()).
by()
{code}
> Better support for aggregation
> ------------------------------
>
> Key: TINKERPOP-1212
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1212
> Project: TinkerPop
> Issue Type: Improvement
> Components: process
> Affects Versions: 3.1.1-incubating
> Reporter: Matthias Broecheler
> Assignee: Marko A. Rodriguez
>
> Currently, it is pretty verbose to write aggregate queries in Gremlin. For
> instance, consider a simple query that asks for the top 10 movies by average
> rating:
> {code}
> g.V().hasLabel("movie").order().by("avgRating",inE("rated").values("rating").mean(),
> decr).limit(10).values("id","name","avgRating")
> {code}
> The problem here is that you have to repeat that nested traversal in order to
> get the actual rating. What's even worse is the fact that this will be
> computed twice. In aggregates, it is very common to order and then retrieve
> by some aggregate. As such, we should be treating those as "virtual
> properties" on the elements that are being aggregated and be able to refer to
> them as properties:
> {code}
> g.V().hasLabel("movie").order().by(inE("rated").values("rating").mean(),
> decr).limit(10).group().by(inE("rated").values('rating').mean())
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
