#953 ✓resolved
Ashley Moran

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")
  it "should make the belongs to not nullable" do
    @child.should be_valid # because we want @parent to tell @child who owns it

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 ||=
      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))


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)

    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)

    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.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

People watching this ticket