SERVER-109703 describes a rewrite which allows a $match to be pushed before a “complex rename” when we know the renamed field does not traverse through arrays. For example:

[
    {$project: {a: "$b.c"}},
    {$match: {a: {$eq: 42}}}
]
---->
[     
    {$match: {“b.c": {$eq: 42}}},
    {$project: {a: "$b.c"}}
] 

This is correct given the knowledge that “b” does not contain arrays.

That ticket is scoped to a particular scenario like the one above where the $project is being used to flatten/unnest a field. That is, the value under “b.c” is moved one level up under “a”. We are prioritizing this because we expect this to be a common pattern with relational migration queries, for example. It should also be a somewhat more straightforward extension given our current code, which only tracks these renames when the new field name is a top-level field.

This ticket represents a handful of extensions to SERVER-109703. Ideas below.

We can support renames when the new name is a nested field, if we know the fields involved are not arrays. For example:

[ 
    {$project: {“a.d": "$b.c"}},
    {$match: {“a.d": {$eq: 42}}} 
]
---->
[     
    {$match: {“b.c": {$eq: 42}}},
    {$project: {“a.d": "$b.c"}}
] 

This will require us to track “complex” (or regular) renames below top-level fields. 

We can support renames when the old name is a more deeply nested field, if we know the fields involved are not arrays. For example:

[ 
    {$project: {“a": “$b.c.d"}},
    {$match: {“a": {$eq: 42}}} 
]
 ----> 
[
    {$match: {“b.c.d": {$eq: 42}}},
    {$project: {“a": "$b.c"}}
] 

This will require us to permit longer field paths on the RHS to be considered as renames.

The solution for this ticket should cover complex renames in $project, $addFields, $set.