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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
What about a before_save callback that checks if the values from other models should be stored locally (status changed and current status == ''Closed'')? -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
> 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. -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On Mon, Dec 15, 2008 at 1:13 AM, Michael Kahle < rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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... -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
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: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org [mailto:rubyonrails-talk@googlegroups.com] On Behalf Of Patrick Doyle Sent: Monday, December 15, 2008 12:26 PM To: rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org Subject: [Rails] Re: Saving a "final" version of a record. On Mon, Dec 15, 2008 at 1:13 AM, Michael Kahle <rails-mailing-list@andreas-s.net<mailto:rails-mailing-list-ARtvInVfO7ksV2N9l4h3zg@public.gmane.org>> 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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
On 16 Dec 2008, at 17:29, Pardee, Roy wrote:> 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.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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---