Viorel wrote:
> It is your decision, but i still say : Don't put calculated values in
> the database.
It really is a question of balance.
Is it better to keep calculated values up to date on the WRITE, or
determine those calculated values on a READ?
If the application will perform a WRITE more
> Why can't my model have calculated values? Right know, my problem is
> that I have a lot of virtual attributes in order to calculate these
> values when I need them. I use this attributes a lot (the virtual
It is a long discussion, but it is a basic principle of any RDBMS. It
is about efficiency
If something needs to be done after create, update and destroy I
believe you need to use both after_save and after_destroy. There are
no single callback that encapsulates all 3.
On Apr 18, 11:15 am, Juan Kinunt wrote:
> Viorel wrote:
> > I think it is a problem with your model. Tou should not hav
Viorel wrote:
> I think it is a problem with your model. Tou should not have fields
> with calculated values, only a method that calculate the value, witch
> you call when you need that value
Why can't my model have calculated values? Right know, my problem is
that I have a lot of virtual attribu
I think it is a problem with your model. Tou should not have fields
with calculated values, only a method that calculate the value, witch
you call when you need that value
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To post to this gr
It sounds like the solution you are looking for is going to require
parsing some JSON, and then handling the update through something like
jQuery.
I'm still trying to wrap my head around AJAX interacting with Rails in
such a way. Before you'd just use RJS, and Prototype would handle the
request, b
6 matches
Mail list logo
