Update related model after_destroy object

Rails
1

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?

2

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, but RJS is so outdated these days.

Maybe you could look up some techniques on updating a record with AJAX
through JSON.

I hope this at least gets you in the right direction… :slight_smile:

3

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

4

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?

5

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.

6

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.

7

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.