#358 ✓resolved
Dusan Maliarik

Collection#keys with resources having nil keys doesn't work

Reported by Dusan Maliarik | June 7th, 2008 @ 11:00 AM

when I am trying to use associations, I'm getting:

NoMethodError: undefined method `size' for nil:NilClass

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/collection.rb:115:in `keys'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/collection.rb:114:in `each'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/collection.rb:114:in `keys'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/collection.rb:10:in `reload'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/resource.rb:512:in `lazy_load'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/resource.rb:90:in `attribute_get'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property.rb:384:in `get'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property_set.rb:61:in `get'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property.rb:514:in `map'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property_set.rb:32:in `each'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property_set.rb:32:in `each'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property_set.rb:61:in `map'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/property_set.rb:61:in `get'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/relationship.rb:54:in `attach_parent'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/one_to_many.rb:196:in `save_resources'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/one_to_many.rb:195:in `each'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/one_to_many.rb:195:in `save_resources'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper.rb:177:in `repository'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/support/kernel.rb:5:in `repository'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/one_to_many.rb:194:in `save_resources'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/one_to_many.rb:188:in `append_resource'

from /usr/lib/ruby/gems/1.8/gems/dm-core-0.9.1/lib/data_mapper/associations/one_to_many.rb:93:in `<<'

from (irb):5irb(main):006:0>

when I switch back to :serial => true, everything is working well

Comments and changes to this ticket

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 7th, 2008 @ 12:52 PM

    According to IRC the code that is causing this problem is:

      employee = Employee.create
      employee.absences << Absences.new

    This is happening inside Collection#keys. It is expecting the Absence resources' primary key to be defined, which it wasn't, because it was defined as :key => true and not :serial => true

    Collection#keys should be updated so that it can handle cases where the resource's key hasn't been defined yet.

    A larger issue tho, is that OneToMany::Proxy#<< will automatically save the resource if the parent is also saved, but if the parent is a new record, it'll append to an Array, and save it at the same time the parent is saved. I think this is in conflict with POLS. I think in every case << should just append to the Array and not be saved until parent.save is called.

    If we still want an approach to automatically save and append in one step, the upcoming Collection#create method should allow it. Since it'll be used within the scope of the one to many relationship, it'll know the foreign key values, and use those as defaults when creating the new resource. We'll need to make a OneToMany::Proxy#create method though to wrap it and append the new resource to the association Array though.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 7th, 2008 @ 12:53 PM

    • Title changed from “:key => true not working” to “Collection#keys with resources having nil keys doesn't work”
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 8th, 2008 @ 06:27 PM

    • Assigned user changed from “Sam Smoot” to “Dan Kubb (dkubb)”
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 8th, 2008 @ 06:34 PM

    • Milestone cleared.
    • State changed from “new” to “open”
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 9th, 2008 @ 07:46 PM

    Sam, please see my above comments.

    Do you mind if i make it so OneToMany::Proxy#<< doesn't automatically save resource in the association. Instead we'd wait until parent.save is called, and save all the children. I think this is consistent with POLS.

    BTW: Collection#create was added, and I actually don't think we'll need a OneToMany::Proxy#create wrapper method as mentioned in my comment above, as I think it satisfies the criteria. As of right now you should be able to go resource.association.create(:foo => 'bar') and have the new resource created within the association only using Collection#create (since it creates the resource within the "scope" of the query)

    Also Collection#keys shouldn't blow up anymore as mentioned in this ticket.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 11th, 2008 @ 12:10 AM

    For the record Sam said it was ok for OneToMany::Proxy#<< to not automatically save. Instead the save should happen when the parent is saved.

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 12th, 2008 @ 05:16 AM

    • State changed from “open” to “resolved”

    Dusan, this issue should be resolved. I am closing the ticket now. Please test your system and if it is still a problem we can reopen this again.

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