Potentially they will be removed in later version.
What are the reasons for that?
I use Server-side JavaScript functions for several IP operations, e.g. convert an IP address to numeric value and back, compose IP subnet, format IPv6 address, etc. Doing it with aggregation pipeline requires a lot more code (which would be just a minor issue) but Server-side JavaScript functions are around 2-4 times faster than native aggregation pipeline function.
Major limitation of aggregation framework is, it lacks binary functions and functions related to HEX conversions, see Support hex conversion and binary operators to aggregation framework, thus it is very cumbersome (and slow) to develop such functions natively in aggregation framework.
Did you find an answer? We also have some uses cases where running server side js is the best solution. There doesn’t seem to be an alternative so I’m wondering why the deprecation…
We currently make extensive use of the MongoDB $function operator across various scenarios. One key use case involves determining which stage of the pipeline an entry was in at a specific time interval, based on an array of historical changes. Another case leverages the operator to calculate the relative value of the currently processed item, based on other elements within the same array.
While it’s possible to rewrite most of these queries using native MongoDB operations, we’ve found that approach to be significantly less performant. Moreover, the resulting queries tend to be more complex, which impacts both readability and maintainability.
We hope that the $function operator remains available, allowing users the flexibility to decide when and how to use it, based on their specific needs.
Hello everyone, the decision to deprecate $function was made based on the security consideration and technical complexity. We don’t have a timeline to remove $function yet and we want to make sure most of our users can replace $function with native MongoDB aggregation or other solutions first.
If any new functionality is needed to rewrite your queries without $function, please either create a SERVER ticket or submit your feedback at feedback.mongodb.com. We will triage all the requests. If you need any further assistant, please reach out to your MongoDB account team or MongoDB support. Thank you!
Well, this doesn’t sound reassuring. You basically didn’t address any of the concerns that your service’s actual users raised. You basically just replied, we will remove it, so deal with it.
It was explained with a lot of solid arguments above that the $function feature is an integral part of many company’s workflows and there is no alternative offered by MongoDB.
I also have a use case where I need to do hashing on a field of millions of records, so the most logical solution is to run that on the server side.
It seems from the answer that MongoDB doesn’t care about offering a performant solution to their users any more…
we want to make sure most of our users can replace $function with native MongoDB aggregation or other solutions first
Well, if this was true, then MongoDB would offer the alternative solutions first, before adding the deprecation notice.
Also, why do we need to submit tickets into a black hole where they end up rejected without any transparency? Isn’t there a community manager in the whole company who actually responds to the community?
This thread is THE feedback, I don’t think there is a need to submit tickets in closed internal tools where they end up ignored.
Which solution do you suggest?
I make extensive use of this operation in my project stage in my pipelines and I don’t have any knowledge of native MongoDB aggregation solutions.
Relying on $function is a risk due to its deprecation path, but at this point MongoDB does not have a plan to eliminate it in any version. When that happens, we would have 30 months of support for it in MongoDB Atlas. Thats a lot of runway to implement around the deprecation then start using newer versions of MongoDB in Atlas.
Also note that $function is implemented into MongoDB Server, meaning you have full control over whether the feature exists by choosing your MongoDB version. Lets say its deprecated in 9.0. Fine. I’ll self-host MongoDB 8.0, stop using Atlas, and be able to still use this feature in the long term. This isn’t like other features in MongoDB Cloud, where it can be deprecated and force a much more disruptive change to happen. You have to weigh the pros and cons, a major con with this approach is being stuck with an old version of Mongo.
It seems weird to deprecate something that is already implemented for security/technical reasons. Couldn’t a flag be provided for customers that want it, and disable it for those that are concerned about security?