Comment 1 for bug 1527342

What data do we want to track for checkout history? We'll need the following columns at minimum on our new table for parity with the TPAC checkout history display.

* id
* xact_start
  -- Set to xact_start from the first checkout in the renewal chain.
* usr
* target_copy
* due_date
  -- Set to due_date of most recent checkout in the renewal chain.
* checkin_time
  -- Checkin time of the most recent checkout in the renewal chain.
  -- Will be NULL until final checkin.
* source_circ
  -- Points to the first circulation in the renewal chain.
  -- Useful for locating the history object during renewal and checkin for modifying dynamic fields (e.g. due_date).
  -- Set to NULL when source circ is aged.

I could see adding these as well:

* circ_lib
  -- Set to circ_lib from the first checkout in the renewal chain.
* checkin_lib
  -- Set to checkin_lib from the last checkout in the renewal chain.
  -- Remains NULL until final checkin.

Alternatively, we could mimic action.circulation entirely and track the entire circulation chain, but that seems like overkill and may be storing more data than we really want to retain.

I would expect rows in the new table being added and updated via DB trigger, which fires on create/update/delete for action.circulation.

Also, there was conversation in bug #1497335 about maintaining static copies of copy/call number/bib data as part of moving checkout history out to its own table, the idea being that a bib record could be modified or deleted, thus changing the history after the fact. I think this is a worthy goal, but it also adds a lot of questions and complications to the implementation. Since the current checkout history implementation does not protect against these kinds of issues, I'm not planning to address it here. That could be added to this new structure later if desired.