You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to parallelize the fetching of included documents, but it would
be tricky to do in the world where these methods are cloning the
response. Instead of trying to do tricky processing on the responses to
merge all the pointers, we can mutate the response in-place.
This kind of in-place mutation can be viewed as more dangerous,
particularly with multiple promises trying to run this kind of
replacement in a row. However, we have some nice guarantees here:
- Each path passed is unique; we don't need to worry about multiple
calls each trying to replace the same documents.
- When we start doing a replacement, all the path prefixes have already
been replaced. In the current implementation this is known because we
sort the include paths by path length, so if a path `a.b.c` is being
processed, then the prefix paths `a` and `a.b` must have already been
processed.
This in-place mutation might also have a nice benefit in terms of memory
usage; queries with lots of includes would have been rebuilding the
result tree multiple times, causing extra allocations. The in-place
method avoids this, and so might reduce memory usage for those queries.
0 commit comments