Has Many w/nested attributes and autosave

[sardjv]

I wanted to put it out there that we've discovered a weird and quite frightening set of behaviour whilst upgrading to Mongoid 7.3 w/Rails 5.2 (I know we're working on it) but it also appears to happens in Rails 6.0.

Suppose we have a class

class User
  include Mongoid::Document
  
  field :name
  
  has_many :friends
  accepts_nested_attributes_for :friends
end

Now from what I can see this is pretty unexciting. I can see that accepts_nested_attributes_for by default sets autosave on the friends association. The behaviour we are seeing that when we save our User, say we're just updating their name every other User is being saved at the same time. I can see that the friends association is being fetched during validation and then consequently since the associated collection is loaded it's being autosaved. So something weird is happening.

I would question at this stage, why we need autosave at all and particularly why it's the default for accepts_nested_attributes.

I know that I take autosaving for granted when using ActiveRecord. My understanding is that you need it to save associations that wouldn't otherwise be saved.

https://docs.mongodb.com/mongoid/current/tutorials/mongoid-relations/#autosaving

If you have a user object and build a new association

user.friends.build(name: 'Dave')
# or
user.friends_attributes=[{name: 'Dave'}]

When you save user it also saves the associated objects you just built. So this behaviour happens without autosave. Do we need it at all? I thought it was there to automatically save associated object whether or not they are persisted or changed?

[braindeaf]

Carrying on the discussion with my actual user. I keep going round and round. I get the impression that validation on associated records is only happening when they are loaded, but if the validator always loads them as a matter of course then this will always happen?

https://docs.mongodb.com/mongoid/current/tutorials/mongoid-relations/#validations

I'm tracing the loading of my association to here. But I don't see why it would load it when it's not necessary.

lib/mongoid/validatable.rb

    def read_attribute_for_validation(attr)
      binding.pry if attr == :friends
      attribute = database_field_name(attr)
      if relations.key?(attribute)
        begin_validate
        relation = without_autobuild { send(attr) } # always loads association??
        exit_validate
        relation.do_or_do_not(:in_memory) || relation
      elsif fields[attribute].try(:localized?)
        attributes[attribute]
      else
        send(attr)
      end
    end

[braindeaf]

Can anyone point me at where the check for whether the association is already loaded or not happens? I assume it's all tied up with autosave at which point I am wondering if we just remove autosave from any non-embedded associations is the correct thing to do.

[braindeaf]

https://jira.mongodb.org/browse/MONGOID-5200

[p-mongo]

Hi @sardjv /@braindeaf,

I am looking into this issue and so far I can offer two thoughts:

1. Why Mongoid enables autosaving when accepting nested attributes: my theory is that, the associations aren't assigned explicitly (i.e. the usage pattern is parent.attributes = many_attributes_including_any_combination_of_assignable_associations), either Mongoid has to track which associations were changed and save them automatically (hence autosaving), or the applications has to do that same task. Making the application do this seems quite onerous to me.

2. The reproduce code in https://github.com/braindeaf/mongoid-autosave-oddity is rather complicated:

class Cat
  include Mongoid::Document
  include Mongoid::Timestamps

  field :name, type: String
  field :answers_to, type: String

  has_and_belongs_to_many :dogs
  has_many :minions, class_name: 'Cat', inverse_of: :leader
  accepts_nested_attributes_for :minions

  belongs_to :leader, class_name: 'Cat', optional: true

  after_save :publish_save_successful

  def publish_save_successful
    true
  end
end

This sets up a self-referential HABTM association. Have you tested a non-self-referential HABTM association (one with two model classes), or a simpler association like has many?

[braindeaf]

Thank you for coming back to me. That test case is the one we are seeing traces of failing so far. However, I'm happy to add more test cases to demonstrate if this is the only situation it fails or if it's more widespread. I'll sort that out this week.

[braindeaf]

Hi there,

So the original association was a self-referential has_many. I added it that way because that was the precise issue we were seeing. I have added w/spec a self referential HABTM, and non-self-referential has_many and HABTM and belongs to demonstrate that records are saved when they don't need to be.

I hope this is helpful :)

[p-mongo]

Hi @braindeaf ,

Thank you for adding those cases. I looked at them and as far as I can tell: the association tries to save itself, this causes individual objects to execute the save methods, this causes validations to run but no writes to the database to happen (since no attributes changed).

I think this behavior is expected. Because any of the autosaved associations could have been changed in the update call, they need to be potentially persisted, hence the save calls on them. Part of saving is execution of callbacks and validations.

Does this make sense to you? If not, can you elaborate on what behavior you are expecting?

[braindeaf]

Problem is we are seeing writes to the database as timestamps update and a page that should be quick is fetching and validating 600 records which in turn could make more calls to the database since you could be checking uniqueness for example. Not to mention callbacks that trigger after save since the record has been forcefully saved. There is no value in fetching records in the first place.

I can spec a nightmare scenario which might better demonstrate this.

[p-mongo]

@braindeaf Yes please, a demonstration would be helpful.