On a web application for accounting services, I have the good old Invoice. To keep this example as simple as possible, each Invoice has many rows, and each row has its item with its price.
At the beginning, the prices of the items are read from a PriceList table.
Each time an invoice is emitted, i store the the key of the item of the PriceList table in my InvoiceRows table.
But prices in PriceList table may change (and often do so) so I've put a price field in the InvoiceRows table, that will contain a copy of the price.
I've managed all this through an ORM (actually i use rails ActiveRecord) but Hibernate would be more or less the same. So my ORM binds some classes, say Invoice and InvoiceRow to the related database tables. Both of them have a save method that persists the data on the database.
I'm quite undecided on where to put the copy logic exposed so far.
Provided that it may go in different places and work well, i'm wondering if there is a well established practice out there.
So far, my idea is the following
Overriding save method
it currently contains the validation and saving logic.
Benefits
It would be impossible forget it. This would be expecially usefull in teams where logic would be 'correct by default'.
Drawbacks
Along the way there may arise cases in which I want to modify a the row without re-copying the values, for example i can have a 'shipping_date' column at row-level that may be modified (and so the row saved) but that doesn't determine the re-copy of the price.
So probably i would force the developer to 'take a stand' on the copy problem and not forget it, rather than allow a single mode of saving records.
That's why in this case it would be better an argument for the save method than a second method called save_whit_price_copy. Because an argument cannot be ignored as you could do with a second method with a different name.
This is more or less the best that I could think of at this point, so I'm wondering if there are other approaches or variations of this that are better than this.