
belongs_to randomly not setting `nullable => false` on associated id property
Reported by Ashley Moran | July 6th, 2009 @ 02:37 PM | in 0.10.0
Disclaimer: this may or may not be reproducible. I've seen it on the mysterious MacBook Pro of the no-longer elusive and mysterious mrship, but I can't make it misbehave on my own MacBook. This ticket is the origin of #952.
The spec file in the attached zip file reads as follows:
describe Parent do
before(:each) do
@parent = Parent.new(:name => "Homer")
@child = Child.new(:parent => @parent, :name => "Bart")
@parent.save
end
it "should make the belongs to not nullable" do
@child.should be_valid # because we want @parent to tell @child who owns it
end
end
The expectation is that it will fail. The reason is that it was
written under the (false) assumption that issue #939 does not
exist. However, I have observed with my own eyes that, sometimes,
DataMapper does not add the presence validation for
parent_id
in Child
. This means the spec
unexpectedly passes. You can see what's going wrong with
the following debug line added to
DataMapper::Associations::Relationship#child_key
:
# Returns a set of keys that identify child model
#
# @return [DataMapper::PropertySet] a set of properties that identify child model
# @api private
def child_key
@child_key ||=
begin
properties = child_model.properties(child_repository_name)
child_key = parent_key.zip(@child_properties || []).map do |parent_property, property_name|
property_name ||= "#{property_prefix}_#{parent_property.name}".to_sym
properties[property_name] || begin
# create the property within the correct repository
DataMapper.repository(child_repository_name) do
p "Creating property #{property_name}", child_key_options(parent_property) # DEBUG
child_model.property(property_name, parent_property.primitive, child_key_options(parent_property))
end
end
end
properties.class.new(child_key).freeze
end
end
When it goes wrong, you can see the :nullable =>
false
being omitted.
As I said above, this appears to be not only intermittent, but possible environment-related. I'll try to gather more information.
Comments and changes to this ticket
-
Dan Kubb (dkubb) July 7th, 2009 @ 02:15 AM
- State changed from new to accepted
- Assigned user set to Dan Kubb (dkubb)
I think I may have a clue as to what is causing this. Working on a fix now. You are not losing your mind, I have a way to reproduce it ;)
-
Dan Kubb (dkubb) August 19th, 2009 @ 12:23 AM
- State changed from accepted to resolved
I wasn't able to reproduce this problem with the supplied code, however I did see some similar issues with another system I work on. One of the reasons was actually due to a design flaw with how inverse relationships were passed around and initialized. I refactored all of the related code, because there were simpler ways to do what I was doing, added some extra specs, and have not been able to reproduce this problem since cleaning things up.
Please retry your app with edge dm-core/next to ensure it is resolved on your end. If it is not, and you are able to reproduce it with a simpler stand-alone app, please attach it to this ticket and I will reopen and investigate.
Marking this ticket as resolved.
Please Sign in or create a free account to add a new ticket.
With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.
Create your profile
Help contribute to this project by taking a few moments to create your personal profile. Create your profile »