As mentioned, a record and a row are referring to the same thing in Cypher. We don't have tables, so we're never referring to a table structure kept as part of the durable graph data.
"Record" is more correct for the reasons you mentioned, and I'd argue that we should probably change the language in our query plans to use "records" and not "rows", that's something I can push for, and it aligns with our usage of "record" in other parts of the Neo4j Browser. It makes sense to standardize the language we use.
That said, when we return these, the most intuitive return format looks a lot like a row. And these rows as a whole appear to make up a table, so we won't completely escape the similarities. We even have a Table result view in the browser.
Yeah, I'm not trying to complain (too much) about semantics. I get why "rows" is totally relevant and helpful, especially for folks coming from table based databases. It's familiar.
well, in the browser when you look at the table view, you see what is basically a collection of hashes. We all know how to dig into a hash, and no reason we couldn't have a dot syntax for that too.
Sure...but we basically have a single column for all the paths. But people don't want to work with a list of paths, they want to use separate variables referring to the parts of the paths (usually nodes) that they are interested in. And they want to perform aggregations, and calculations, and projections, so you're usually not going to be working with pure paths at the end.
GraphQL responses aren't that much different than Cypher results...it's just a JSON representation of the results. But returning just a giant JSON structure of results isn't really the best when you're anticipating a lot of results, or if you're trying to do something like export to a CSV
Got it. It does depend upon what is important to each user, for what they want returned. For some paths are the most important. And it also varies for the kinds of queries you want to run.
We're flexible, but that flexibility introduces complexity, no real way around that.
I guess put a better way, if the result you desire are the paths, then work with the path variables in addition to the important components of the path.
But for many many queries, paths are just a means to an end, not the end itself. For example, if you only need, per movie, the movie title and the names of actors (and you have no need to visualize it graphically), then the paths don't matter in the end.
If you want to calculate the average ratings given to a movie, when returning the final results you don't care about all the tens of thousands or more :REVIEW relationships between people and the movie, you just want to output the movie, and the calculated average review score. Having to output all path results that were referenced to calculate the average isn't useful, and will make the query slower and output far more than what's needed.