
Problem with loading associations (associated objects) in specific case
Reported by Matevz Rostaher | March 16th, 2009 @ 04:19 AM
Hi!
I'm running into a problem where a previously saved 1:N association doesn't load in another unit of work. Basically I have two classes (ObjectA and ObjectB) and two 1:n associations (assoc1, assoc2) between these, navigable in both directions. Then I create two instances of ObjectA (a1, a2) and an instance of ObjectB (b). In a second step I connect a1 to b using assoc1 and a2 to b using assoc2, of course bi-directional. In a thrid step I first load all three again and after that try to navigate from a1 to b using the assoc1 association. This navigation doesn't retrun the expected b object. Each of the steps are done it's own unit of work and transaction.
The problem is best described with the test at the bottom of the message + attached as a file
I tried to debug it (using Eclipse DLTK) and the problem doesn't appear if I step trough the code.
I'm running Ruby 1.8.7, dm-core 0.9.10, data_objects 0.9.11 and do_sqlite3 0.9.11 on Windows XP and Ubuntu 8.10.
Best regards and thank you for any help in advance, Matevz
require "rubygems" require "test/unit" require "dm-core"
class ObjectA include DataMapper::Resource property :id, Integer, :serial => true property :field1, String has n, :assoc1 , :class_name => 'ObjectB', :child_key => [:assoc1_id] has n, :assoc2 , :class_name => 'ObjectB', :child_key => [:assoc2_id] end
class ObjectB include DataMapper::Resource property :id, Integer, :serial => true property :field2, Integer belongs_to :assoc1_back, :class_name => 'ObjectA', :child_key => [:assoc1_id] belongs_to :assoc2_back, :class_name => 'ObjectA', :child_key => [:assoc2_id] end
class AssociationLoadingTest < Test::Unit::TestCase def setup
DataMapper.setup(:default, "sqlite3::memory:")
DataMapper.auto_migrate!(:default)
end
def testProblem
DataMapper.repository(:default) do
ObjectA.transaction do
a1 = ObjectA.new(:field1 => '1')
a2 = ObjectA.new(:field1 => '2')
b = ObjectB.new(:field2 => 1)
b.save
a1.save
a2.save
end
end
DataMapper.repository(:default) do
ObjectA.transaction do
a1 = ObjectA.get(1)
a2 = ObjectA.get(2)
b = ObjectB.get(1)
a2.assoc2 << b
b.assoc2_back= a2
a1.assoc1 << b
b.assoc1_back= a1
b.save
a1.save
a2.save
puts "a1 after saving= #{a1}"
puts "a1.assoc1 after saving = #{a1.assoc1.first}"
end
end
DataMapper.repository(:default) do
ObjectA.transaction do
a1 = ObjectA.get(1)
a2 = ObjectA.get(2)
b = ObjectB.get(1)
assert_equal(1, a2.assoc2.size)
assert(a2.assoc2.first.equal?(b))
assert(a2.assoc2.first.assoc2_back.equal?(a2))
# all three asserts below fails for unknown reason:
# the instance of B is not demand-loaded
puts "a1 after reloading= #{a1}"
puts "a1.assoc1 after reloading= #{a1.assoc1.first}"
assert(a1.assoc1.first.equal?(b))
assert_equal(1, a1.assoc1.size)
assert(a1.assoc1.first.assoc1_back.equal?(a1))
end
end
end end
Comments and changes to this ticket
-
Dan Kubb (dkubb) May 28th, 2009 @ 07:14 PM
- State changed from unconfirmed to accepted
- Assigned user set to Dan Kubb (dkubb)
-
Dan Kubb (dkubb) June 7th, 2009 @ 02:28 AM
- State changed from accepted to resolved
I've completely rewritten the association system in the dm-core/next branch and just ran your test case against it with no failures.
I am going to mark this ticket as resolved for now, but if you can reproduce your problem with the dm-core/next branch please add a comment here and I will reopen this ticket.
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 »