Closed theodorDiaconu closed 12 months ago
I would say that we have a problem in aggregation pipeline. I think this would be better:
[
{
"$match": {
"bId": {
"$in": [
"xbghvEDmn79A9ZS4f"
]
}
}
},
{
"$project": {
"ratings.rating": 1,
"ratings.dimension": 1,
"bId": 1
}
},
{
"$group": {
"_id": "$bId",
"data": {
"$push": "$$ROOT"
}
}
}
]
In that way grapher is not required to know details of the database schema and we basically have identical approach in both find
and aggregate
- via projection. Which would probably be something what you meant under 1) - DB is doing all the work regarding fields.
Additional benefit - we do not require dotted field replacement anymore. Regarding performance, I think we are good here since we are doing $project before $group.
I tried to fix this and it looks like it is not complicated, you can see this commit.
All tests are passing with that changes (of course, including the failing one you wrote).
@theodorDiaconu What do you think?
@bhunjadi look here https://github.com/kaviarjs/nova/tree/master/src/core/query/hypernova how I approached it in the npm version. I would have merged it completely. But meta links
have been an extreme pain to implement, and do nicely.
Here is another attempt - using find
instead of aggregate
.
Works with meta links.
Caveat: slicing (limit, skip) cannot be done on db server since results are not grouped. But this applies to all links, not just meta.
This approach is similar to npm version, but handles meta links and supports slicing
Looks good, let's bring it here in a PR
It could be closed in favor of #400
Closing in favor of #400
There is a failing test here, and it's related to retrieving nested objects from the reverse side. As you can see in tests.
The problem basically is this, when we perform the aggregation:
Which is ok, but when we get the response its:
Even if ratings looks like:
Possible solutions