I came about this problem because I am using Dynamoid in a Rails Engine, and I discovered issues where the relationships between models were not functioning correctly due to the isolate_namespace functionality of engines.
For example, piggybacking off the example in the README, if I had classes like this, but in an engine named MyEngine...
module MyEngine
class User
include Dynamoid::Document
# ...
has_many :addresses
end
end
module MyEngine
class Address
include Dynamoid::Document
# ...
belongs_to :user # Automatically links up with the user model
end
end
In other words, the MyEngine::Address ID would not be saved on the MyEngine::User dynamo record.
This is because in this line of code in belongs_to.rb, the MyEngine::Address class would evaluate to :"my_engine/addresses" which of course is incorrect.
My solution is to check if both the target_class and the source_class share the same module_parent, check that that module parent custom to the app, and then use the demodulize functionality to strip the class down to its bare name.
I came about this problem because I am using Dynamoid in a Rails Engine, and I discovered issues where the relationships between models were not functioning correctly due to the
isolate_namespace
functionality of engines.For example, piggybacking off the example in the README, if I had classes like this, but in an engine named
MyEngine
...I would get the following in a rails console
In other words, the
MyEngine::Address
ID would not be saved on theMyEngine::User
dynamo record.This is because in this line of code in
belongs_to.rb
, theMyEngine::Address
class would evaluate to:"my_engine/addresses"
which of course is incorrect.My solution is to check if both the
target_class
and thesource_class
share the samemodule_parent
, check that that module parent custom to the app, and then use thedemodulize
functionality to strip the class down to its bare name.