While upgrading to Machinist 2, I had a hell of a time getting blueprints with associations to actually save.
The problem turned out to be that the code was using
validates_presence_of :hometown_id, where
hometown is the name of the association, and the solution is to use
validates_presence_of :hometown, or the newer version:
validates :hometown, presence: true.
If you have a given class:
1 2 3 4 5
1 2 3 4
Viking.make will properly return an unsaved Viking object (with a Hometown object
valid? will return false.
Viking.make! will throw an exception:
ActiveRecord::RecordInvalid: Validation failed: Hometown can't be blank
If you really want to keep using
validates_presence_of :hometown_id, you can modify the blueprint like this:
1 2 3 4
Then Viking.make! will succeed. Viking.make will also work, and will return an unsaved Viking object, but it will actually create and save the associated Hometown object, which negates part of the point of calling
.make instead of
make creates objects but does not save them to the database, giving quite a performance boost for test suites).
The proper solution is to adjust the validation in your model:
1 2 3 4 5 6
The key is that we’ve changed
validates_presence_of :hometown_id to
validates :hometown, presence: true. The validation actually checks the association itself, not the presence of an id field (which is only ever set once the hometown is saved).
We’ve also added a
validates_associated :hometown call, which will check
hometown.valid? before saving, and if the hometown fails validation, then the viking object will as well.
See API docs about validations here: