feat(NODE-4738)!: remove dot notation support by default

[baileympearson]

Description

What is changing?

The Filter and UpdateFilter types have been reverted to pre-dot notation support.
Additionally, new types StrictUpdateFilter and StrictFilter are exported for consumption. These types are experimental and provide the same dot-notation functionality as version 4.13.0 of the driver but they are not used in any driver CRUD APIs.

Is there new documentation needed for these changes?

Yes.

Double check the following

• Ran npm run check:lint script
• Self-review completed using the steps outlined here
• PR title follows the correct format: type(NODE-xxxx)[!]: description
  • Example: feat(NODE-1234)!: rewriting everything in coffeescript
• Changes are covered by tests
• New TODOs have a related JIRA ticket

[avaly]

[dariakp]

@avaly Yes, we are aware - unfortunately there were a lot of unintended consequences in making this the default behavior, which is why we are preserving it in an opt-in capacity and will consider options for integrating it more naturally in the future. We are leaving it marked experimental because we have not had the opportunity to test it as thoroughly as something with such wide-reaching scope would merit. In retrospect, we should have taken the time to do a technical design to fully define the intended boundaries of the functionality - but we were excited and it did seem to "just work". We would like to take a step back now and give this feature the attention it deserves, which we cannot do right this moment. Until we are able to prioritize this work, we are definitely open to feedback from the community to help guide this in the right direction.

[avaly]

Thanks @dariakp for the message!

Will the mongodb team accept pull requests regarding these strict filter types? Or would you like to keep those as-is until the team has resources to make those a priority?

[dariakp]

@avaly We are open to accepting PRs, with the caveat that as experimental features, triage and review of changes to these types will fall lower on our priority list than bugs or improvements to our officially supported features. However, our ultimate goal with these experimental types is to get them into a form that our users find most helpful, so we will consider all feedback we get: whether through PRs, Jira tickets, or comments.

One thing to keep in mind is that the current StrictFilter is intended to be strict on known schema fields, but to allow for unknown $-operators (because the driver does not attempt to exhaustively catalogue all available server-side operators), so improvements to that type would need to adhere to that design intent. If there is a use case for restricting the set of allowed operators, we are open to considering a separate experimental type.

[avaly]

Thanks again for the honest response.

We (at Plex) have build Papr with full type-safety in mind from day 0. That's why we opted to submit all these features upstream to the driver. But given these shifted priorities in the driver project, we will copy these types in our library code to be able to move faster (plexinc/papr#410).

[dariakp]

@avaly We strive for transparency :) As far as dot notation support: we'll be sure to follow your version of the types and consider them in any future updates to ours. Thank you again for making the original contribution!

[avaly]

As mentioned previously, we're adopting these strict types in our Papr library to be able to iterate on them faster and introduce more strictness: plexinc/papr#430

@dariakp Would your team be interesting in getting some of these changes submitted in PRs here?

I know some changes will probably not be accepted (e.g. removing recursive types support), so I won't bother submitting those. But how about the other parts?

[dariakp]

@avaly As long as they come with tests and don't run counter to the objectives I mentioned above for StrictFilter, we welcome any improvements to functionality :)