doesn't create associations that use a :class_name (v2)

[inspire22]

class Topic < blah
  belongs_to :last_user, :class_name => 'User'
  validates_presence_of :last_user_id
end

Topic.blueprint do
  title {Faker::Lorem.words}
  rendered {Faker::Lorem.paragraphs(3)}

  #just assumes make? i think so, but needs adding to machinist docs!
  board #{Board.make!}
  user
  # gr, not making last_user.  frustrating...
  last_user_id {u=User.make!; puts "last_user is #{u.id}"; u.id}

end

Topic.make! -> last_user_id can't be null. it also puts 'last user is 51', but apparently doesn't set it.

Also doesn't work with last_user {User.make!} or just 'last user' in the blueprint.

[ReneB]

I've isolated this issue to the inclusion of Rake. make - require 'rake' - make-one-more demonstrates that in the first call, the associated object is created, and in the second call, it is not. This also happens if another gem in, for example, the Gemfile, requires 'rake'
require 'spec/mocks'
require 'spec/blue_prints'
puts Drive::FileShare.make.file_id.inspect
require 'rake'
puts Drive::FileShare.make.file_id.inspect

results in:
2633
nil

[ReneB]

Ouch, this is painful. The problem turns out to be different, but perhaps closely related: the blueprints for Drive::FileShare include an attribute called 'file'. However, requiring 'rake' introduces a globally-available method 'file' into your code. Therefore, the attribute in the blueprint-DSL is not seen as attribute, but as a call to Object#file:

Drive::FileShare.blueprint do
  file
end

Possibly, a similar error exists in the OP's codebase - either the method last_user might already exist, or some other problem with namespace pollution might exist.

[notahat]

Yep, global methods suck.

You can work around this in the blueprint by doing:

bc. Drive::FileShare.blueprint do
self.file
end