-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Behavior of $project
for nested documents
#4704
Comments
Another datapoint: Concluding from the point of investigation, the goal was to derive the field name from a property. Therefore, paths use the segment after the dot. We never tested against paths containing multiple segments as the flaw that we resort to the first dot would have been revealed. We should update this behavior with our next major release to correctly derive the field name and also verify functionality against placeholder paths ( |
project
for nested documents$project
for nested documents
Hi. I'm trying to understand the overloaded
project
methods in an aggregation. My initial understanding was thatproject("x")
is only the short form ofproject(Fields.from(field("x")))
or evenproject(Fields.from(field("x", "x")))
. The latter variant is of course only really needed if you want to project a field to a model with a different structure. This assumption is true for top level fields. However when used for nested documents the resulting queries look a bit different and don't work as expected. See the following example:There is a record
RootDocument
at the bottom which contains a nested documentLevelOneDocument
with only one fieldlevelOneField
. TheRootDocument
also contains theid
which is irrelevant here and another fieldlevelOneField
. This one should not be here and I only added it to demonstrate the problem. When you run the first two aggregations (project("...")
andproject(Fields.from(field("...")))
) they both produce the same query which leads to the wrong result - i.e. "$levelOneDocument.levelOneField" is projected to "levelOneField". Only when you explicitly state that you want to project "levelOneDocument.levelOneField" to "levelOneDocument.levelOneField" (the third aggregation -project(Fields.from(field("...", "...")))
) you get the expected query and result.The reason for the resulting query in the first two aggregations is a check in org.springframework.data.mongodb.core.aggregation.Fields:238. It checks whether
name
contains a period andtarget
is null. In this case only the substring after the first period is used as name. I'm not sure what the intention of this code is. Maybe a period has a special meaning in a projection that I'm not aware of. If this is the case this should be documented somewhere. Otherwise if you only look at the overloaded methods you would assume that they all behave similarly, regardless whether you project a top level field or a nested document.The text was updated successfully, but these errors were encountered: