Difference between revisions of "What do the psc fields do?"

From LinuxMCE
Jump to: navigation, search
(Imported document)
 
m (beautification)
 
(2 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
<table width="100%"> <tr><td bgcolor="#FFCFCF">This page was written by Pluto and imported with their permission when LinuxMCE branched off in February, 2007.  In general any information should apply to LinuxMCE.  However, this page should be edited to reflect changes to LinuxMCE and remove old references to Pluto.</td></tr> </table><p>When you add a table to a repository sqlCVS adds 5 fields to the end of the table, which is how the client side keeps track of changes.  Normally you don't need to worry about the fields--they all have default values that accomplish their purpose, which is:</p>
+
[[category: Programmer's Guide]]
−
<p><b>psc_id</b>  Every record needs a globally unique id which never changes.  This cannot be the primary key since the primary key can be changed, and then there is no way to know if this is a new record or what the original value was.  So the psc_id has a default value of NULL.  When the client side does a checkin, all rows where psc_id is null must be new rows because during the checkin process they will be given permanent id's by the server.</p>
+
[[category: tutorials]]
−
<p><b>psc_batch</b>  Every time you check-in or commit your local working copy, all the changes you made are put into a "batch", which is like a revision.  This field contains the last batch, or revision, which modified this row.</p>
+
When you add a table to a repository sqlCVS adds 5 fields to the end of the table, which is how the client side keeps track of changes.  Normally you don't need to worry about the fields--they all have default values that accomplish their purpose, which is:
−
<p><b>psc_user</b>  Every user is given a unique ID.  The sqlCVS program has a ValidateUser module that can be replaced by a developer to accomodate any type of back-end user authentication, such as LDAP, active directory, or some other database.  This module also handles validating users' passwords, determining who is a supervisor, and mapping the psc_user to a real user account.</p>
+
−
<p><b>psc_frozen</b>  If you set this field to 't' that means the record is frozen.  sqlCVS can't stop the local client from making changes to the record in his local copy, but it does prevent him from checking those changes in to the master database.  When he attempts to checkin changes to a frozen record or table, those changes will be stored in a special "unauthorized batch", recognizeable because the batch number is negative.  At checkin time he will be given the unauthorized batch number, which he can give to a supervisor.  If a supervisor decides he wants the changes merged in anyway he can use the "Approve Batch" command to apply them.</p>
+
−
<p><b>psc_mod</b>  This is a timestamp field.  Everytime a record is changed MySql will automatically set the timestamp field to the current date/time.  During the checkin process psc_mod will be set to 0 as the row's changes are sent to the server.  So any rows where psc_mod is not 0 have been modified and those changes need to be checked in.</p>
+
  
 +
===psc_id=== 
 +
Every record needs a globally unique id which never changes.  This cannot be the primary key since the primary key can be changed, and then there is no way to know if this is a new record or what the original value was.  So the psc_id has a default value of NULL.  When the client side does a checkin, all rows where psc_id is null must be new rows because during the checkin process they will be given permanent id's by the server.
 +
 +
===psc_batch=== 
 +
Every time you check-in or commit your local working copy, all the changes you made are put into a "batch", which is like a revision.  This field contains the last batch, or revision, which modified this row.
 +
 +
===psc_user=== 
 +
Every user is given a unique ID.  The sqlCVS program has a ValidateUser module that can be replaced by a developer to accomodate any type of back-end user authentication, such as LDAP, active directory, or some other database.  This module also handles validating users' passwords, determining who is a supervisor, and mapping the psc_user to a real user account.
 +
 +
===psc_frozen===
 +
If you set this field to 't' that means the record is frozen.  sqlCVS can't stop the local client from making changes to the record in his local copy, but it does prevent him from checking those changes in to the master database.  When he attempts to checkin changes to a frozen record or table, those changes will be stored in a special "unauthorized batch", recognizeable because the batch number is negative.  At checkin time he will be given the unauthorized batch number, which he can give to a supervisor.  If a supervisor decides he wants the changes merged in anyway he can use the "Approve Batch" command to apply them.
 +
 +
===psc_mod===
 +
This is a timestamp field.  Everytime a record is changed MySql will automatically set the timestamp field to the current date/time.  During the checkin process psc_mod will be set to 0 as the row's changes are sent to the server.  So any rows where psc_mod is not 0 have been modified and those changes need to be checked in.

Latest revision as of 21:47, 17 May 2010

When you add a table to a repository sqlCVS adds 5 fields to the end of the table, which is how the client side keeps track of changes. Normally you don't need to worry about the fields--they all have default values that accomplish their purpose, which is:

psc_id

Every record needs a globally unique id which never changes. This cannot be the primary key since the primary key can be changed, and then there is no way to know if this is a new record or what the original value was. So the psc_id has a default value of NULL. When the client side does a checkin, all rows where psc_id is null must be new rows because during the checkin process they will be given permanent id's by the server.

psc_batch

Every time you check-in or commit your local working copy, all the changes you made are put into a "batch", which is like a revision. This field contains the last batch, or revision, which modified this row.

psc_user

Every user is given a unique ID. The sqlCVS program has a ValidateUser module that can be replaced by a developer to accomodate any type of back-end user authentication, such as LDAP, active directory, or some other database. This module also handles validating users' passwords, determining who is a supervisor, and mapping the psc_user to a real user account.

psc_frozen

If you set this field to 't' that means the record is frozen. sqlCVS can't stop the local client from making changes to the record in his local copy, but it does prevent him from checking those changes in to the master database. When he attempts to checkin changes to a frozen record or table, those changes will be stored in a special "unauthorized batch", recognizeable because the batch number is negative. At checkin time he will be given the unauthorized batch number, which he can give to a supervisor. If a supervisor decides he wants the changes merged in anyway he can use the "Approve Batch" command to apply them.

psc_mod

This is a timestamp field. Everytime a record is changed MySql will automatically set the timestamp field to the current date/time. During the checkin process psc_mod will be set to 0 as the row's changes are sent to the server. So any rows where psc_mod is not 0 have been modified and those changes need to be checked in.

Retrieved from "http://wiki.linuxmce.org/index.php?title=What_do_the_psc_fields_do%3F&oldid=23806"