views:

202

answers:

2

I am currently building a rails application based around insurance. There is an admin section where the staff can control the system tables, mostly what appears in drop down lists, although some are more complex with their own associations. The main model in this application is the policy, this needs to hold/link to information in many other tables, e.g. claimants, defendants, the level of cover, the users etc. Each of those may have their own associations such as linking to a person which in turn links to addresses etc.

One of the more complicated tables that the policy links to is the overall level of cover which holds the financial information to determine the premium, payments etc.

When a policy is created I need to take a snapshot of all that data. If the policy is amended by an admin user later there needs to be version control, even on the associated data.

I'm wondering if anyone has any general solutions to this problem. Currently I'm pondering over orphan records, single table inheritance, leaving the system table links in place but making that data non-editable, coping the data into a fields in the policy table (making it a text box on edit, select box on create) or creating two tables, one for live, one for the templates.

So far the best I can think of is a collection of the different methods above based on the applications needs. This must be a general problem in applications!? Do you have any better ideas/advice on how to tackle this type of problem?

+1  A: 

For versioning of models, vestal_versions (github.com/laserlemon/vestal_versions) plugin might be helpful.

Selva
link was broken. http://github.com/laserlemon/vestal_versions/ is what it should be. Found a railscast too: http://railscasts.com/episodes/177-model-versioningI can't +1 this answer enough. I haven't used vestal_versions, but it claims to do the right things, and I have seen the damage of trying to roll your own. A DRY versioning system is just what you want. It isn't a trivial thing that you can just crank out yourself for one project.
cgr
I really like the look of vestal_versions, I haven't looked at too much yet but I don't think it handles the associations? I would love to be wrong on that though.
tsdbrown
+1  A: 

Without knowing exactly the needs of the application it is difficult to determine what the best solution is.

However the solution that immediately comes to mind for me based upon what I have read would be the "orphaned records" that you describe, but I do not see why they need to be orphaned.

You could create a model like this:

class PolicyHistory< ActiveRecord::Base
   belongs_to :policy
end

class Policy < ActiveRecord::Base
has_many :policy_histories
end

The policy History could contain your snapshot of all the policy details and associated data at a particular moment and even who made the changes.

You could flatten the associations and store that data in a bunch of columns. However this may cause issues when altering any of the involved table since you will have to update the history table as well.

A solution to this might be serializing the complete snapshot as a hash. The policy history table would then be able handle any changes to the involved tables.

I hope this is of some help to you!

rube_noob