Issue: belongs_to with validate: false and optional: false no longer allows saving the child when parent is invalid in Mongoid 9

[lucasDechenier]

Context

I'm upgrading an application from Mongoid 7.4.0 to Mongoid 9.0.4, and I encountered a change in how belongs_to associations behave when using:

belongs_to :test_parent, validate: false, optional: false

In Mongoid 7.4.0, this configuration allowed the child to be persisted, even if the parent was invalid and not persisted, because validate: false meant the association wouldn’t be validated.

Behavior in Mongoid 7.4.0 (expected and working)

parent = TestParent.new # invalid, missing name
child = TestChild.new(title: 'Child', test_parent: parent)

child.save # => true

Result:

• child is persisted with test_parent_id
• parent is not persisted (as expected)
• No validation error occurs
• Association lookup (child.test_parent) returns nil unless manually saved

Behavior in Mongoid 9.0.4 (unexpected regression)

Using the exact same models and test, the behavior changed:

parent = TestParent.new # invalid
child = TestChild.new(title: 'Child', test_parent: parent)

child.save # => false

Mongoid refuses to persist the child, even though validate: false is explicitly set.

Minimal Reproducible Example

require 'rails_helper'

class TestParent
  include Mongoid::Document
  field :name, type: String
  validates :name, presence: true
  has_one :test_child
end

class TestChild
  include Mongoid::Document
  field :title, type: String
  belongs_to :test_parent, validate: false, optional: false
end

RSpec.describe 'Mongoid belongs_to validation behavior' do
  it 'persists child even if parent is invalid' do
    parent = TestParent.new # invalid
    parent.save(validate: false) # skip validation
    expect(TestParent.count).to eq(1)

    child = TestChild.new(title: 'Child', test_parent: parent)
    result = child.save 
    expect(TestChild.count).to eq(1)
    expect(result).to be true
  end
end

Actual Result in Mongoid 9.0.4

• child.save returns false
• No exceptions are raised, but the document is not persisted
• Over 300 tests broke in my application due to this change

Additional note

Using optional: true across all associations is not a viable workaround in my case, because optional: true introduces another inconsistency, where assigning an object to the foreign key field (*_id) causes serialization errors.

expect {
  TestTrackEmail.create!(
    email: '[email protected]',
    test_company_id: company # passing object instead of company.id
  )
}.to raise_error(BSON::Error::UnserializableClass)

Because of this, applying optional: true globally across all belongs_to associations in my application caused over 100 test failures, especially in scenarios where foreign keys were being assigned document objects instead of raw IDs.

Additionally, the expectation is that setting validate: false should disable validation entirely for that association—regardless of whether optional is true or false. Requiring both validate: false and optional: true to bypass validation behavior goes against that design intention and causes inconsistencies.

Question

Shouldn't validate: false skip validation and allow saving even when optional: false?

Is this behavior change intentional?
If so, is there a workaround to restore the previous behavior without rewriting all associations or saving parents manually?

Impact

This change introduces implicit cascade validation behavior that was not present in earlier versions and breaks expectations around validate: false. It affected large portions of our codebase where we relied on this to defer validation of associated documents.

The validate: false is not respected

Any clarification or guidance would be appreciated.

[jamis]

Lucas, the situation you're in is understandably painful and frustrating. I hate that we don't have any good workaround for you.

To answer your questions:

• The change you describe was introduced in Mongoid 8.0.1. While it was well-documented in those release notes at the time, that documentation has gradually become overgrown with newer release announcements and is no longer very visible. If upgrading from 7.x directly to 9, it's understandable how it would have been missed.
• The change was intentional (see https://jira.mongodb.org/browse/MONGOID-4160), but it's clear that the full impact of the change was not entirely understood. We've learned a lot of lessons over the last 3 years or so about how to better communicate and handle breaking changes; this change is probably not one we would make in the same way today with the lessons we've learned since.
• We expect to revisit this in the future, but because changing it now would just compound the problem with more backwards breaking changes, we can't do anything significant about it in the 9.x series. (Though we hope to tackle https://jira.mongodb.org/browse/MONGOID-5851 soon, which will add the feature flag that you mentioned should have been added originally.)

Again, we really are sorry for the mess. If you'd like to brainstorm about possible workarounds, I'd be happy to participate, but I fear there will be no silver bullet for it in the immediate future.

[lucasDechenier]

Thank you for your response, Jamis. I really appreciate your time and the transparency.

I’d like to share some thoughts from the perspective of a product that relies heavily on MongoDB, including using paid services like Atlas clusters.

For our application, this change represents a massive amount of work. It’s something we now must tackle in order to upgrade Mongoid and keep using the latest MongoDB driver in our infrastructure. It’s unfortunate, because this specific change — while perhaps well-intentioned — could have been much more manageable had it included a global opt-in flag to preserve legacy behavior (e.g., allowing children to be saved even when their parents are invalid). This was possible before and worked quite well in our case.

MongoDB is, after all, a non-relational database. What surprises me is that the team didn’t seem to fully consider the implications for polymorphic or loosely coupled data models, where validation at the parent level doesn’t always make sense. In our system, many of these validations were intentionally skipped — now with this change, all of them silently fail when saving children, which breaks the flexibility that drew us to MongoDB in the first place.

One of the reasons we adopted MongoDB was precisely to avoid the rigid constraints of SQL databases, and to work with dynamic data in a more pragmatic way. Unfortunately, this change seems to go in the complete opposite direction. I apologize if I sound frustrated — I truly am, and I’m just trying to be honest about our experience.

We haven’t found any viable workaround that doesn’t feel like a hack. At this point, our team has reluctantly decided to remove belongs_to associations entirely and replace them with just foreign key IDs in the model. It’s not ideal, but honestly, it seems like the least painful path forward.

I’ve read through the discussions and I believe that MONGOID-5851 should also include the ability to skip validation on belongs_to, not just on the embedded children. That would restore the flexibility many systems need. If a client wants stricter consistency, validate: true should be enough to enforce that. It feels very unintuitive that validate: false doesn’t behave as expected — and instead, optional: true becomes the only way to skip validation.

In the end, this change imposes a very high operational cost on us, and the unfortunate reality is that the best answer right now seems to be “there's nothing to be done.” Like you, I wish there was something that could be done — even if just to offer a backward-compatible opt-out for this behavior.

Thanks again for listening.

[jamis]

I will add that the following may work for you, though it is the worst kind of monkey-patching:

module WorkAroundBelongsToValidation
  private

  def setup_instance_methods!
    define_getter!
    define_setter!
    define_existence_check!
    define_builder!
    define_creator!
    define_autosaver!
    define_counter_cache_callbacks!
    polymorph!
    define_dependency!
    create_foreign_key_field!
    setup_index!
    define_touchable!

    # The following line changes the conditions under which the association is added; it better copes with
    # the otherwise-conflicting `:optional` and `:validate` options, only letting the `:optional` option dominate
    # if `:validate` has not been set.
    @owner_class.validates_associated(name) if validate? || (require_association? && @options[:validate].nil?)

    @owner_class.validates(name, presence: true) if require_association?
  end
end

Mongoid::Association::Referenced::BelongsTo.prepend(WorkAroundBelongsToValidation)

[jamis]

@johnnyshields -- part of the problem here is that you can't remove the belongs_to validation if optional: false is set. That's the heart of the bug, here. If you set optional: false, then the validation will fire regardless of the value of validate:.

[lucasDechenier]

You're absolutely right @johnnyshields , and I agree with @jamis — the root issue is that optional: false always enforces the validation, even when validate: false is set. Unfortunately, switching to optional: true isn't a safe workaround either, because it introduces another inconsistency where assigning an object directly to the foreign key (*_id) can lead to serialization errors.

[comandeo-mongo]

@lucasDechenier You mentioned that you were upgrading to 'keep using the latest MongoDB driver in our infrastructure'. Sorry for guessing, but if this is the main reason for upgrading, you could try just using the latest driver with Mongoid 7.x, which might eliminate the need for all the hassle involved in upgrading. This combination is not officially supported, but it might work for you.

Also, older versions of the driver connect to current servers. If you are not planning to use the latest server's new features, the older driver will usually work.

I understand how this all sounds, but since we cannot reasonably provide a real solution fast, I think this may be worth considering as a temporary one. Please feel free to reach out to me if you decide to give it a try and encounter any issues.

I am terribly sorry that we do not have anything better for you at the moment.

[lucasDechenier]

@comandeo-mongo Thanks for the suggestion, I really appreciate your help and honesty.

That said, using a MongoDB driver version that’s not officially supported by the Mongoid version in use may not be considered a good practice in our environment. Unfortunately, I won’t be able to get approval from management to go with such an approach.

So for now, we're going down the path of refactoring our code to adapt — as frustrating as that might be.

[johnnyshields]

@comandeo-mongo @jamis It would be great if you could release a version of MongoDB 7.x that supports the latest driver. This would really help users (including myself) with upgrading, so at least we can upgrade the BSON/Driver versions before doing the Mongoid upgrade.

(I have actually already hacked Mongoid to use the latest driver/BSON, so I can say for a fact it's pretty easy to do--nothing has broken in terms of compatibility, all you'll need to do is loosen gemspec restrictions.)