I've run into another scenario which I think is related to this feature request.
Take the IMDB example: the graph has movie nodes, and each movie has one or more genres/categories. You could express this as a property on each node, or you could have formal genre nodes that movies are connected to. Either way, the scenario is this: we want to show an "overview" page that shows the most popular movies for each category. E.g. it shows the top 5 comedy movies, the top 5 action movies, drama, horror, and so on. We can't figure out how to do this in one Cypher query. We can ORDER BY and LIMIT, but that's for the whole set, where we want to do this per category. The closest we've come up with is to return all movie+category pairs -- both as just UUIDs to be efficient (see other thread where I've asked for first-class ID support) -- along with the stats for each movie, and then we sort on the client, then we load the movie data for the top 5 per category. This isn't a bad result, but it feels a bit hacky/manual. Would love if Cypher supported this kind of thing directly. It's almost like grouping results and being able to order/limit within groups. But it's also just another first-degree / second-degree scenario. Food for thought. =) Thanks for the consideration! Aseem On Thu, Aug 25, 2011 at 2:00 PM, Aseem Kishore <[email protected]>wrote: > Thanks Andrés! > > Couple of random extensions to the thoughts above: > > - To be consistent, perhaps for "optional matches", the results could > always include a row where that optional match was ignored. That way, > "Elizabeth, <null>" wouldn't be an inconsistency; *every* first-degree > friend would have an "[friend], <null>" row. > > - And perhaps *that* row could be the one that has the full node data, and > every subsequent row for the second optional match would just reference the > URL/ID of the first-degree node. > > After chewing on this a lot more, though, I've realized that what I really > want in this scenario is not tabular data, but a real subgraph. Hence my > email just now. =) > > Aseem > > > On Thu, Aug 25, 2011 at 1:34 PM, Andres Taylor < > [email protected]> wrote: > >> Good and valid requests, Aseem. >> >> Consider them heard. We'll see how soon we can get it to you. >> >> Andrés >> >> On Thu, Aug 25, 2011 at 12:57 PM, Aseem Kishore <[email protected] >> >wrote: >> >> > Man, I am loving Cypher. Thanks so much guys for introducing it. I'm a >> bit >> > stuck on one query, though, and I wanted to ask for help. I think the >> > reasons I'm stuck are related to the two feature requests I made >> yesterday >> > (optional matches, and returning IDs). >> > >> > I want to fetch first- and second-degree friends in one query, in a way >> > that >> > preserves the first-degree friend(s) for each second-degree friends. >> Assume >> > an asymmetrical friendship model, like Twitter's following, because that >> > makes things a bit easier. >> > >> > Here's a simple transitive example: >> > >> > - Alice follows Bob and Carol. >> > - Bob follows Carol and Dave. >> > - Carol follows Dave and Alice. >> > >> > >> > I want to fetch Alice's first-degree friends (Bob and Carol) and each of >> > their first-degree friends ((Carol and Dave) for Bob, and (Dave and >> Alice) >> > for Carol). This example is easy enough: >> > >> > START zero=(Alice) >> > MATCH (zero) -[:FOLLOWS]-> (first) -[:FOLLOWS]-> (second) >> > RETURN first, second >> > >> > >> > I expect to get back results like: >> > >> > - Bob, Carol >> > - Bob, Dave >> > - Carol, Dave >> > - Carol, Alice >> > >> > >> > This is great because I can get Alice's first-degree friends by >> > unique()'ing >> > the first column, for each person, I know their second-degree friends >> via >> > the second column. >> > >> > But this doesn't work if any of my first-degree friends don't follow >> > anyone. >> > For that, it would be great if I could specify that the second part of >> that >> > match was "optional", and I'd get back a row like this in that case: >> > >> > - Elizabeth, <null> >> > >> > If I'm returning nodes, it also duplicates a ton of info: each >> first-degree >> > friend's info is returned in full for each of their friends. Maybe >> there's >> > no way around that, but this is also where I would find it convenient to >> be >> > able to return IDs somehow for all but one of the results. >> > >> > Just thinking out loud here, but I'd greatly appreciate any feedback or >> > ideas for this scenario. Thanks much! >> > >> > Aseem >> > _______________________________________________ >> > Neo4j mailing list >> > [email protected] >> > https://lists.neo4j.org/mailman/listinfo/user >> > >> _______________________________________________ >> Neo4j mailing list >> [email protected] >> https://lists.neo4j.org/mailman/listinfo/user >> > > _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
