The old_reserves table is meant to be a historical preservation of data. Currently it has foreign keys a number of tables where that also have a delete/old table for preservation. For example, we may have an "old reserve" with an associated item. When we delete that item, the item is moved to the deleteditems, and old_reserves.itemnumber is set to NULL thus losing the associated item even though we still have the item data! This is true for borrowers, bibs and items. To enable saving this data, we should add a non FK column for each related table that has a delete/old version of that table. Then, when the associated item is deleted, copy the FK value to the new column before is is nullified. In fact, if we populated those columns when moving the hold from reserves to old_reserves, we wouldn't even have to add code to each of the delete methods!
I think this is the solution for bug 36101, but I am not sure about doubling up the data. We could imagine having a FK on deleteditems if we add the information on delete for example.
(In reply to Katrin Fischer from comment #1) > I think this is the solution for bug 36101, but I am not sure about doubling > up the data. > We could imagine having a FK on deleteditems if we add the information on > delete for example.
Kyle? :)
(In reply to Katrin Fischer from comment #3) > Kyle? :) I was ready to write a against your suggestion when I decided you were correct and i just changed the see also (iirc) while forgetting about the reply box being populated. We'd need a hook of some kind to handle this either way. If we do it my way, it's a minimum of one hook firing. Doing it at "deletion" time, it's also a maximum of one hook firing :)
(In reply to Kyle M Hall from comment #4) > (In reply to Katrin Fischer from comment #3) > > Kyle? :) > > I was ready to write a against your suggestion when I decided you were > correct and i just changed the see also (iirc) while forgetting about the > reply box being populated. We'd need a hook of some kind to handle this > either way. If we do it my way, it's a minimum of one hook firing. Doing it > at "deletion" time, it's also a maximum of one hook firing :) Ah! But hope you now I would not have minded if you had disagreed - it's about to find the best way forward :)