If you update the id of a linked table in the model, wouldn’t you expect
the rails framwork to immediately take this into account?
what I mean is:
rates table
id currency_id name
1 1 “rate 1”
2 1 “rate 2”
currencies table
id name
1 “GBP”
2 “USD”
3 “EUR”
assume models have the correct belongs_to and has_many statements.
rate = Rate.find(1)
puts rate.currency.name # GBP
rate.currency_id = 2
puts rate.currency.name # still GBP
But,
rate = Rate.find(2)
rate.currency_id = 2
puts rate.currency.name # USD
I understand why this - in the first example, we’ve already retrieved
the associated currency record, so it doesn’t re-retrieve it for the
second puts. But isn’t this a bug? Shouldn’t rails invalidate the
cached associated record when the currency_id field is changed? Or is
this a config setting somewhere?
sr
i dont think its a bug.
did you try this:
rate = Rate.find(1)
puts rate.currency.name
rate.currency_id = 2
rate.save
puts rate.currency.name
That should work. And it makes sense that it works like this.
Otherwise you could forget to actually update the record in the
table, and get strange bugs. Rails forces you to save the changed
record so the tables stay in sync with your changes …
That’s how i see it.
Thorsten L wrote:
i dont think its a bug.
did you try this:
rate = Rate.find(1)
puts rate.currency.name
rate.currency_id = 2
rate.save
puts rate.currency.name
That should work. And it makes sense that it works like this.
Otherwise you could forget to actually update the record in the
table, and get strange bugs. Rails forces you to save the changed
record so the tables stay in sync with your changes …
That’s how i see it.
Yes, that will work, but isn’t applicable in an application where you
want to allow the user to play around with various options before saving
it to the database. If you save after he’s made each change, you’ve got
to work out how to get back to the original position should he abandon
the update.
sr
its no bug. in his second example, he did not load the associated
records before changing the primary key, so they weren’t cached, but
retrieved from the database.
However, i think my argumentation from the previous post is not really
solid, but i think i just just found the solution.
It’s all in the API docs.
See rails API FOR: ActiveRecord::Associations::ClassMethods
Quote:
"Adds the following methods for retrieval and query for a single
associated object that this object holds an id to. association is
replaced with the symbol passed as the first argument, so belongs_to
:author would add among others author.nil?. "
- association(force_reload = false) - returns the associated object.
Nil is returned if none is found.
EndofQuote
so something like this should work, not tested though
rate = Rate.find(1)
puts rate.currency.name
rate.currency_id = 2
rate.currency(true)
puts rate.currency.name
"Adds the following methods for retrieval and query for a single
associated object that this object holds an id to. association is
replaced with the symbol passed as the first argument, so belongs_to
:author would add among others author.nil?. "
- association(force_reload = false) - returns the associated object.
Nil is returned if none is found.
EndofQuote
so something like this should work, not tested though
rate = Rate.find(1)
puts rate.currency.name
rate.currency_id = 2
rate.currency(true)
puts rate.currency.name
Thorsten,
This appears to be just what we’re looking for. We’ll try it out and
let you know.
sr
Thorsten L wrote:
i dont think its a bug.
did you try this:
rate = Rate.find(1)
puts rate.currency.name
rate.currency_id = 2
rate.save
puts rate.currency.name
That should work. And it makes sense that it works like this.
Otherwise you could forget to actually update the record in the
table, and get strange bugs. Rails forces you to save the changed
record so the tables stay in sync with your changes …
That’s how i see it.
If that was the case then why would his second example work. Sounds like
a (small) bug to me!