# Saving a "final" version of a record **URL:** \ **Category:** Rails\ **Created:** [December 15, 2008, 7:13am UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640 "2008-12-15T07:13:39Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 15, 2008, 7:13am UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/1 "2008-12-15T07:13:39Z")
I’ll start by apologizing for the title. I can’t think what to call this. I have some Claims that need to be entered, but when they are “closed” it saves the data from other related tables into the Claim (this could get messy), so that if the Customer, Registration, or Dealer information is changed at a later date it will remain the same as when the Claim was closed. Is there a preferred method for doing this? Some kind of plugin or something? I understand I could have a separate table for keeping the “archived” version of the record, but I fear the work to create all new tables and then storing the record as this other new archive type which is nothing more than a duplicate of the Claim. Any thoughts? P.S. - Ask away, I am probably not explaining this perfectly, but I will try to elaborate if you are having trouble understanding my challenge. ---
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 15, 2008, 7:06pm UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/2 "2008-12-15T19:06:28Z")
What about a before\_save callback that checks if the values from other models should be stored locally (status changed and current status == ‘Closed’)? ---
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 15, 2008, 7:34pm UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/3 "2008-12-15T19:34:02Z")
> I have some Claims that need to be entered, but when they are “closed” > it saves the data from other related tables into the Claim (this could > get messy), so that if the Customer, Registration, or Dealer information > is changed at a later date it will remain the same as when the Claim was > closed. > Michael, I completely understand your dilemma. I spent quite a bit of time on a claims application myself. I can tell you that your statement, “This could get messy.” is certainly true. Unfortunately, I don’t know any way around it not being “messy.” I don’t know of any plugins or such that would help here, but maybe there are some. The approach I took was to treat models related to the claim as “templates” for filling in the claim records. In my case this system was for the trucking industry. So I had to deal with information about truck drivers, claimants, insurance companies, etc. My system would capture a “snapshot” of a driver (for example) and copy that data to a separate table that was then related to the claim. Then I provided a way for the user to update the driver’s data in the claim to the latest version in the original driver record, but only if the claim was open. Once closed the update feature was no longer available. I realize this is not ideal, but the alternative wasn’t much better. I suppose I could have done the update automatically on save depending on the state of the claim. But, I chose instead to allow the user to update at their own discretion. In my case some of the data needed to be captured (and frozen) based on the date of loss. We needed to know the driver attached to an order on the date of loss. So even if the order was assigned a new driver we still needed to capture the original driver’s information that was involved in the claim. Which meant that is data had to be frozen when the claim was created, not when it was finally closed. ---
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 16, 2008, 3:49am UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/4 "2008-12-16T03:49:28Z")
Thank you Robert and Patrick for such thought provoking posts. Notice how both of you are saying similar things to what Ar first suggested? > Ar called it a “before\_save callback function.” > > > Robert suggested, “I suppose I could have done the update > > automatically on save depending on the state of the claim. > > But, I chose instead to allow the user to update at their > > own discretion.” > > > > > Finally Patrick thought of the copy-on-write feature. This got me thinking about rsync, or git; even Apple’s Time Machine. All of these programs store data in a “state” that allows you to view the changes over a period of time. What is this design pattern called? Has it been written about? The software we use to run the business where I am employed has something like this on the accounting side. The whole, “close out the month”, feature. Humm… ---
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 15, 2008, 9:26pm UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/5 "2008-12-15T21:26:51Z")
On Mon, Dec 15, 2008 at 1:13 AM, Michael K. \< removed\_email\_address@domain.invalid\> wrote: > Is there a preferred method for doing this? Some kind of plugin or > try to elaborate if you are having trouble understanding my challenge. I wonder if you could implement a “copy-on-write” feature in the Customer, Registration, Dealer, etc… tables. Basically, add a “freeze\_record” boolean column to those tables and set that to “true” when you need to finalize one of those records. If you ever want/need to update a frozen record, you could allocate a new one, scan all of the claims to which this record “belongs\_to” and point all of those that are not closed to the new record. This strikes me as an ideal candidate for some sort of plugin that mixes into ActiveRecord. Unfortunately, I haven’t the foggiest idea how to implement the practical side of this theoretical solution (yet… but I’m learning more every day). –wpd ---
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 16, 2008, 5:30pm UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/6 "2008-12-16T17:30:21Z")
In the olden days we would do this sort of thing with db triggers and a ‘journal’ table–every UPDATE would result in a record\_version field being incremented, and the pre-update version of the rec written out to a separate table. You can also keep all record versions in one table & put up a view that selects out just the most recent, but that can be problematic perf-wise. (IIRC, chunks of SAP do the all-versions-in-one-table thing.) Agree that an AR plugin should be able to handle the journaling–not sure if there is one that does. I vaguely recall an ‘acts as deleteable’ or ‘acts as archivable’ plugin discussed here a while back that seems like similar functionality–not sure if it would get you all the way there. * * * From: removed\_email\_address@domain.invalid [[mailto:removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)] On Behalf Of Patrick D. Sent: Monday, December 15, 2008 12:26 PM To: removed\_email\_address@domain.invalid Subject: [Rails] Re: Saving a “final” version of a record. On Mon, Dec 15, 2008 at 1:13 AM, Michael K. \ wrote: I’ll start by apologizing for the title. I can’t think what to call this. I have some Claims that need to be entered, but when they are “closed” it saves the data from other related tables into the Claim (this could get messy), so that if the Customer, Registration, or Dealer information is changed at a later date it will remain the same as when the Claim was closed. Is there a preferred method for doing this? Some kind of plugin or something? I understand I could have a separate table for keeping the “archived” version of the record, but I fear the work to create all new tables and then storing the record as this other new archive type which is nothing more than a duplicate of the Claim. Any thoughts? P.S. - Ask away, I am probably not explaining this perfectly, but I will try to elaborate if you are having trouble understanding my challenge. I wonder if you could implement a “copy-on-write” feature in the Customer, Registration, Dealer, etc… tables. Basically, add a “freeze\_record” boolean column to those tables and set that to “true” when you need to finalize one of those records. If you ever want/need to update a frozen record, you could allocate a new one, scan all of the claims to which this record “belongs\_to” and point all of those that are not closed to the new record. This strikes me as an ideal candidate for some sort of plugin that mixes into ActiveRecord. Unfortunately, I haven’t the foggiest idea how to implement the practical side of this theoretical solution (yet… but I’m learning more every day). –wpd ---
**Author:** ![mrkohrea](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/4491bb/32.png) [@mrkohrea](https://www.ruby-forum.com/u/mrkohrea)\ **Post date:** [December 16, 2008, 5:49pm UTC](https://www.ruby-forum.com/t/saving-a-final-version-of-a-record/155640/7 "2008-12-16T17:49:09Z")
On 16 Dec 2008, at 17:29, Pardee, Roy wrote: > deleteable’ or ‘acts as archivable’ plugin discussed here a while > back that seems like similar functionality–not sure if it would get > you all the way there. There’s also acts\_as\_git: [http://www.caboo.se/articles/2008/11/15/new-plugin-acts\_as\_git](http://www.caboo.se/articles/2008/11/15/new-plugin-acts_as_git) All plugin based solutions have an impact on performance, don’t know how good or bad acts\_as\_git does it. Since it uses text files to version records and works on a field-by-field basis, I wouldn’t get my hopes up all too much. Maybe the developer himself can chime in on this thread. Best regards Peter De Berdt