Saving a "final" version of a record

Rails
1

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.

2

What about a before_save callback that checks if the values from other
models should be stored locally (status changed and current status ==
‘Closed’)?

3

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.

4

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…

5

On Mon, Dec 15, 2008 at 1:13 AM, Michael K. <
[email protected]> 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

6

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: [email protected]
[mailto:[email protected]] On Behalf Of Patrick D.
Sent: Monday, December 15, 2008 12:26 PM
To: [email protected]
Subject: [Rails] Re: Saving a “final” version of a record.

On Mon, Dec 15, 2008 at 1:13 AM, Michael K.
<[email protected]mailto:[email protected]>
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

7

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

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