[Nitro] Inconsistent data with refers_to fixed

Aleksi Niemela Aleksi.Niemela at cs.helsinki.fi
Wed Sep 7 16:44:29 EDT 2005

I was bit by tihs again. This time debugging for few hours before I was 
on top of how things worked out.

This time I had an User and an Order each pointing to each other.  Then 
I said

   user.active_order = other_user.active_order

which changed user.active_order_oid to other_user.active_order.oid but 
it didn't change user. at active_order which continued to point "old 
order". I had to see what was really in the database and what was in the 
memory to find out the reason. Rediscoved the behavior. Luckily at this 
point I remembered we have had discussion about it already.

George, why do you still think it's good to have behavior like it is 
currently? Code like following doesn't really work like I expect.

  foo.bar = some_bar
  foo.bar = some_other_bar
  foo.save!           # doesn't do what I expect

I expect foo on memory be equivalent to one on database. And save! 
doesn't help either as foo. at bar continues to refer to an some_bar it has 
been referring all the time, no matter we just assigned it to point to 

    - Aleksi


Aleksi Niemela kirjoitti:

> George Moschovitis wrote:
>>> 2) Even if auto-reloading of incorrect references is not wanted,
>>> previous version of refers_to doesn't reload if forced, so there's a 
>>> bug
>>> to be fixed. (It's easy for me to rip the above mentioned third case
>>> away, and the bug stays fixed.)
>> please, remove the third case, i think that autoreloading of incorrect
>> references is not wanted by default (i 'll add an Og option for this).
> Actually you were quicker! But yes, the bug regarding reloading is now 
> fixed with in current version (earlier checkin fixed that already) and 
> the code doesn't have handling for the third case (as you removed it). 
> There are still a point I'd like to highlight. I checked in a working 
> version of tc_relation.rb which reflects the current state of affairs.
> I'm posting this mail to list so you can beware and not get bitten by 
> this feature. For me this feature of refers_to pointing to incorrect 
> object in memory but doing just ok in database forces my code to be 
> full of
>  managed_object.referring_to(true).property_foo
> type of code which reloads referred objects all the time (just to be 
> sure they're like they're on disk).
> Thanks,
>    - Aleksi
> Here's the relevat part of the test case demonstrating the effect.
>  def test_refers_to
>    og = Og.setup(:store => :memory, :name => 'test')
>    og.manage_classes
>    # test refers_to accessor is correctly updated
>    u = User.create("George")
>    a = Article.create("Og is a good thing!")
>    assert_equal(nil, a.active_user)
>    a.active_user = u
>    a.save!
>    assert_equal(u.oid, a.active_user_oid)
>    assert_equal(u.object_id, a.active_user.object_id)
>    u2 = User.create("Another user")
>    a.active_user = u2
>    a.save!
>    assert_equal(u2.oid, a.active_user_oid)
>    # Note! Og doesn't automatically reload object referred by active_user
>    # so this won't equal.
>    assert_not_equal(u2.object_id, a.active_user.object_id)
>    # Even forced reload won't help here as it won't reload relations.
>    a.reload
>    assert_not_equal(u2.object_id, a.active_user.object_id)
>    # But forcing enchanted accessor to reload in refers_to.rb helps!
>    a.active_user(true)
>    assert_equal(u2.object_id, a.active_user.object_id)
>    # and just to be sure oids are still correct
>    assert_equal(u2.oid, a.active_user_oid)
>  end
> _______________________________________________
> Nitro-general mailing list
> Nitro-general at rubyforge.org
> http://rubyforge.org/mailman/listinfo/nitro-general

More information about the Nitro-general mailing list