- Request #161 (A. Bhaskaran): Add new column description to Applications table
------------------------------

Provides information about a channel list/applications regarding its purpose, reason for creation, RT or PP programs
that might use it, whether it is a filter for another channel list, etc.

==> Approved.


- Request #152 (P. Friberg): VERSION table for tracking database changes
----------------------------

Version table to be added to track the version of the AQMS DB installed at a site.

Fields:
    version       - a number that increments with each version
    tracking_info - the SVN tag or release number or git URL to grab that version
    lddate        - when was this DB updated

Then we start tracking this in our DB repo for any changes and provide new insert
statements for the VERSION table after we make any changes.

==> Approved.
Add 'remark - Optional remarks' field.
Track schema and stored procedures changes.

==> PF to work with RH on setting up the table on PostgreSQL instances.
Version stored as String. Start with 1.1.0 (major, minor, patch level).
Table contains version history.


- Request #159 (R. Hartog): PCS_STATE table Primary Key
---------------------------

From Renate:

I changed the PCS function and kept the primary key the same (group,source,state,id), and though we have not run
into issues, I am not very satisfied with the level of testing that we have done. However, that is what is in the
DB/branches/uw-dev-branch/DBpg directory. That is the only DB directory suitable for PostgreSQL, the rest of the
DB/ stuff is all Oracle specific.

It would be more safe to make the PK: group,source,state,id,rank (CalTech) or even more permissive group,source,state,id,lddate (UCB).

==> Feedback from Pete in NC:

Stephane,

Here's what you wrote in 2009:
 > I talked to Hal last night and he said that it is common for the analysts
 > to press the Finalize button more than one time because sometimes they
 > don't remember if they pressed it or not. Every time they press it,
 > Jiggle inserts a FINALIZE row in the PCS_State table.
 > This seems to introduce some replication conflicts sometimes when an
 > analyst finalizes an event more than once within a short time on one
 > data center database and the PCS system is processing them on the
 > other data center database.
 > I am thinking that if I add the 'lddate' field to the primary key for
 > the PCS_State table, it might alleviate this problem because each
 > row will be uniquely identified.
 > 
 > My question is: by adding the lddate field as part of the primary key,
 > will it affect any of the PCS codes? I wouldn't think so but want to
 > double check with you first.

I think this change worked, since I don't recall hearing about PCS_STATE
replication issues in a long time. And the timers still "finalize" events
multiple times.

I don't have a problem with having "rank" as part of the primary key. We don't
use different rank values so it doesn't matter to us.

Pete