Update related model after_destroy object

Hi!,

I know that Rails do not save in cascade so I need to solve this problem: I have invoice that has lines. Invoice have fields that are calculated with values of lines so when a line is modified or deleted I need to update the invoice, how I do that automaticaly? If I use before_save on invoice it does nothing because it does not detect that a line related is modified. Is the best solution to use a after_save on line that updates the invoice?

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

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 attributes in order to calculate these values when I need them. I use this attributes a lot (the virtual attributes are total and tax of invoices that are calculated from the lines of the invoices) and the app have efficienty problems. I use this attributes for searching, doing statistics, calculate another values...so I have decided to store them in the database. Each time a line is created, modified or deleted the corresponding invoice is updated. What do you think about this implementation?

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.

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 also. Just think about it.

Each time a line is created, modified or deleted the corresponding invoice is updated.

So, this calculations are made anyway, even if you don't need the values. Plus, you need to be very sure that the value is updated every time it need to be and that can be very complicated. I don't think that the efficiency problem' ppears because too many virtual fields. It is your decision, but i still say : Don't put calculated values in the database.

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 frequently than a READ, or even in a roughly equivalent frequency, then calculate on a READ.

If the application will be doing more READs than WRITEs, then calculate and store the values upon WRITE. The more often the READs are done, the better for your throughput. The more expensive (processing-wise) your calculations are, the better for your throughput.

In Juan's case, I don't think I would do it on a per-lineitem for the invoice, but I would do it on persisting the invoice. Give the user the option to 'recalc my bill' if they really wanted to see the fully determined invoice, but on the first addition or deletion or change of a lineitem, I'd clear the subtotal, taxes, and total, and show/enable the 'recalc now'.

If a user is sitting down to enter 10 lineitems, don't let the 'automatic calcs' get in the way of the users throughput in entering those 10.