On Tue, Sep 30, 2008 at 9:13 PM, Anthony E. [email protected] wrote:
Something like this: @book.price = $20.00
@book.save() @stats.save()
Anthony,
Is Book the only model that you’ll be doing this for? …or are there
other models that will use this historical log of prices?
There’s a few options here. One, you could add method to be called by
after_save to check the price previously stored with the new one… if
they are different… add a new entry to the historical log.
Another option is to not store prices in the Book model and only in
another table called something like BookPrice.
book has_many book_prices
Then you can scope book_prices for current to do something like:
book.book_prices.current.price # => get the current price
book.book_prices.each { |book_price| … } # => iterate through all
book prices
Anyhow, there’s a few options to throw your way. Good luck!
Cheers,
Robby
–
Robby R.
Chief Evangelist, Partner
PLANET ARGON, LLC
design // development // hosting
Book having many :prices does make sense. That way you get to keep
the history of the price of the book. Of course, the latest price in
the association is the current price.
Book having many :prices does make sense. That way you get to keep
the history of the price of the book. Of course, the latest price in
the association is the current price.
Ramon T.
The problem with that is to get the current price (most uses cases) I
have to scan the entire ‘prices’ table.
I’d rather do it in such a way that it only saves the current price,
year, edition, etc. to a “stats” whenever the book is updated (without
any explicit association).
On Tue, Sep 30, 2008 at 9:13 PM, Anthony E. [email protected] wrote:
Something like this: @book.price = $20.00
@book.save() @stats.save()
Anthony,
Is Book the only model that you’ll be doing this for? …or are there
other models that will use this historical log of prices?
There’s a few options here. One, you could add method to be called by
after_save to check the price previously stored with the new one… if
they are different… add a new entry to the historical log.
Another option is to not store prices in the Book model and only in
another table called something like BookPrice.
book has_many book_prices
Then you can scope book_prices for current to do something like:
book.book_prices.current.price # => get the current price
book.book_prices.each { |book_price| … } # => iterate through all
book prices
Anyhow, there’s a few options to throw your way. Good luck!
Cheers,
Robby
Thanks Robby.
I will be doing this for one model for now, perhaps others down the
road.
The “Book” model has numeric attributes that I want to save into a
“statistics” table so I can draw a line-graph over time from it.
Other attributes would be archived as well.
Its sounds to be a before_update would give me access to the current
price. And I don’t want to keep the current price in a stats table
because that table will eventually grow and slow down the regular query.
book
id
title
price
edition
year
stats
id
book_id
price
edition
year
created_at
updated_at
Ideally sans-rails the stats table would be populated with a trigger
when the book table is updated.
There book will definitely “has_many :stats” but I don’t really want
that association to be queried every time I get a regular book object,
only when I build the stats page.
Seriously, with database indexes… this is doubtful to be an issue.
If it’s ever an issue you can cache the current price in the book
model, but really… I wouldn’t be concerned about that for a while.
I’d rather do it in such a way that it only saves the current price,
year, edition, etc. to a “stats” whenever the book is updated (without
any explicit association).
This is the case either way. Just not convinced you need to cache this
in the Book model from the get-go, which is what you’re leaning
toward.
Cheers,
Robby
–
Robby R.
Chief Evangelist, Partner
PLANET ARGON, LLC
design // development // hosting
Seriously, with database indexes… this is doubtful to be an issue.
If it’s ever an issue you can cache the current price in the book
model, but really… I wouldn’t be concerned about that for a while.
I’d rather do it in such a way that it only saves the current price,
year, edition, etc. to a “stats” whenever the book is updated (without
any explicit association).
This is the case either way. Just not convinced you need to cache this
in the Book model from the get-go, which is what you’re leaning
toward.
Thanks Robby, you may indeed be correct.
Is it safe to say your recommendation is to create a model for each
statistical attribute I want to archive?
ie:
Price
Year
Edition
…and associate them to the Book via: has_many and then use the most
recent as the current price?
I can’t get the save to work across the association. The price is coming
from a backend system un-related to rails so I have got the data itself
no problem with “get_price” and saving it to self.price is fine…but I
can’t refactor this into saving to another model (ie: prices)
Book < ActiveRecord::Base
has_many :prices
before_save :get_price
after_save :set_price
def get_price
price = Legacy::Data.new().price
end
At this point my understanding breaks down…how do I save that
“get_price” value to the “Prices” model?
#brokenzy
def set_price @price = self.prices.new @price.price = self.price
end
Seriously, with database indexes… this is doubtful to be an issue.
If it’s ever an issue you can cache the current price in the book
model, but really… I wouldn’t be concerned about that for a while.
I’d rather do it in such a way that it only saves the current price,
year, edition, etc. to a “stats” whenever the book is updated (without
any explicit association).
This is the case either way. Just not convinced you need to cache this
in the Book model from the get-go, which is what you’re leaning
toward.
Thanks Robby, you may indeed be correct.
Is it safe to say your recommendation is to create a model for each
statistical attribute I want to archive?
ie:
Price
Year
Edition
…and associate them to the Book via: has_many and then use the most
recent as the current price?
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.