Database Data Management - Revision history

Sallain at 21:43, 11 February 2020

2020-02-11T21:43:43Z

Joseph: updated release names 1.0 -> 0.10 and 1.1 -> 1.0

2013-03-14T00:17:09Z

updated release names 1.0 -> 0.10 and 1.1 -> 1.0

Joseph: /* For the future Releases */

2012-10-10T20:41:45Z

For the future Releases

Joseph at 21:13, 24 September 2012

2012-09-24T21:13:03Z

Joseph: /* Release */

2012-09-19T22:18:04Z

Release

Joseph: /* For the 1.1 Release */

2012-09-19T22:11:34Z

For the 1.1 Release

Joseph: /* Development */

2012-09-19T22:09:46Z

Development

Joseph at 22:08, 19 September 2012

2012-09-19T22:08:32Z

Joseph at 21:39, 19 September 2012

2012-09-19T21:39:00Z

Joseph: Created page with "Main Page > Development > Development documentation > Database Data Management Category:Development documentation =For the..."

2012-09-19T21:24:24Z

Created page with "Main Page > Development > Development documentation > Database Data Management Category:Development documentation =For the..."

New page

[[Main Page]] > [[Development]] > [[:Category:Development documentation|Development documentation]] > Database Data Management
[[Category:Development documentation]]

=For the 1.0 Release=
The data for the transcoder will need to be maintained by the FPR. The table structure will be maintained by the package.

All pk INT's will be replaced will UUIDs.
This will allow for local customizations to be distinguished from the original data provided in archivematica.

All tables will have a replaces UUID column added.
This column will be populated when a provided rule is replaced with an updated/custom one.
As part of the update, the system will need to

Last updated.

==Development==
To separate data for the transcoder, we'll be using a series of mysql dumps. Once the FPR data is seperate, the developer can work on a means of populating that into their database, with the columns they require, and getting them into the database through an API.

=For the 1.1 Release=

==Development==

==Editing Data==

=For the future Releases=

@@ Line 2: / Line 2: @@
 [[Category:Development documentation]]
-=For the 1.0 Release=
+=For the 0.10 Release=
 The data for the transcoder will need to be maintained by the FPR. The table structure will be maintained by the package.
@@ Line 20: / Line 20: @@
 ==Release==
-A custom script for updating from the 0.9 to 1.0 will be developed to track existing SIPs/Tranfers/Files in the system, and not lose any data associated with them. This should be a msyql script to be run by the tool Austin has found for managing DB's across releases. Issue 1226.
+A custom script for updating from the 0.9 to .10 will be developed to track existing SIPs/Tranfers/Files in the system, and not lose any data associated with them. This should be a msyql script to be run by the tool Austin has found for managing DB's across releases. Issue 1226.
-=For the 1.1 Release=
+=For the 1.0 Release=
 Development changes for the db will occur through a sql script, applied against the previous release. Issue 1227.
 ==Development==
-The 1.0 schema will remain in the code. Rebuilding the database will consist of the following steps:
+The .10 schema will remain in the code. Rebuilding the database will consist of the following steps:
-# Build the database from the 1.0 schema
+# Build the database from the .10 schema
 # Apply update patch sql script file
 # Run update script, that will replace the updated rows where specified.
-The 1.0 schema will remain untouched from the 1.0 release.
+The .10 schema will remain untouched from the .10 release.
-<br/>The apply patch will be edited to make changes for the 1.1 release.
+<br/>The apply patch will be edited to make changes for the 1.0 release.
 <br/>The update script will be developed for this release.
@@ Line 39: / Line 39: @@
 ==Release==
-Updating from 1.0 to 1.1 can run the patch. This requires no data loss.
+Updating from .10 to 1.0 can run the patch. This requires no data loss.
-New installs will run a script generated as part of the release process. It will be a dump of the 1.0 with the 1.1 patch applied. Future releases will use this as the base for development in the next release.
+New installs will run a script generated as part of the release process. It will be a dump of the .10 with the 1.0 patch applied. Future releases will use this as the base for development in the next release.
 ==Deployed Data management==
-Same as 1.0
+Same as .10
 ==How this works with local customizations==
-The local customization made in 1.0 will not be overwritten by the ones made in the update, because all the fk's will already have been updated, so there would be nothing to replace, and point at the new rule.
+The local customization made in .10 will not be overwritten by the ones made in the update, because all the fk's will already have been updated, so there would be nothing to replace, and point at the new rule.
 =For the future Releases=

← Older revision		Revision as of 20:41, 10 October 2012
Line 52:		Line 52:
	Each release keeps the base sql dump from the previous release.		Each release keeps the base sql dump from the previous release.
	A patch file is generated against this dump for the release.		A patch file is generated against this dump for the release.
		+	We could look at generating the patch using http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

@@ Line 5: / Line 5: @@
 The data for the transcoder will need to be maintained by the FPR. The table structure will be maintained by the package.
-All pk INT's will be replaced will UUIDs.
+All pk INT's will be replaced will UUIDs. Issue 1223.
 This will allow for local customizations to be distinguished from the original data provided in archivematica.
-All tables will have a replaces UUID column added.
+All tables will have a replaces UUID column added. Issue 1224 .
 This column will be populated when a provided rule is replaced with an updated/custom one.
 As part of the update, the system will need to identify items that have been replaced, and update the foreign keys pointing at it to the updated rule. Warning: not all foreign keys are explicit in the database. Some are a "combined foriegn key", like Tasks Configs: Task type will inform the code what table to look at, and taskTypePKReference will specify the fk.
 ==Development==
-To separate data for the transcoder, we'll be using a series of mysql dumps. Once the FPR data is seperate, the developer can work on a means of populating that into their database, with the columns they require, and getting them into the database through an API.
+To separate data for the transcoder, we'll be using a series of mysql dumps. Issue 1225. Once the FPR data is seperate, the developer can work on a means of populating that into their database, with the columns they require, and getting them into the database through an API.
@@ Line 20: / Line 20: @@
 ==Release==
-A custom script for updating from the 0.9 to 1.0 will be developed to track existing SIPs/Tranfers/Files in the system, and not lose any data associated with them. This should be a msyql script to be run by the tool Austin has found for managing DB's across releases.
+A custom script for updating from the 0.9 to 1.0 will be developed to track existing SIPs/Tranfers/Files in the system, and not lose any data associated with them. This should be a msyql script to be run by the tool Austin has found for managing DB's across releases. Issue 1226.
 =For the 1.1 Release=
-Development changes for the db will occur through a sql script, applied against the previous release.
+Development changes for the db will occur through a sql script, applied against the previous release. Issue 1227.
 ==Development==
@@ Line 41: / Line 41: @@
 Updating from 1.0 to 1.1 can run the patch. This requires no data loss.
-New installs will run a script generated as part of the release process. It will be a dump of the 0.9 with the patch applied. Future releases will use this as the base for development in the next release.
+New installs will run a script generated as part of the release process. It will be a dump of the 1.0 with the 1.1 patch applied. Future releases will use this as the base for development in the next release.
 ==Deployed Data management==

@@ Line 39: / Line 39: @@
 ==Release==
-Updating from 1.0 to 1.1 can run the patch.
+Updating from 1.0 to 1.1 can run the patch. This requires no data loss.
 New installs will run a script generated as part of the release process. It will be a dump of the 0.9 with the patch applied. Future releases will use this as the base for development in the next release.

@@ Line 24: / Line 24: @@
 =For the 1.1 Release=
+Development changes for the db will occur through a sql script, applied against the previous release.
 ==Development==
@@ Line 47: / Line 47: @@
 ==How this works with local customizations==
 The local customization made in 1.0 will not be overwritten by the ones made in the update, because all the fk's will already have been updated, so there would be nothing to replace, and point at the new rule.
 =For the future Releases=
 Each release keeps the base sql dump from the previous release.
 A patch file is generated against this dump for the release.

← Older revision		Revision as of 22:09, 19 September 2012
Line 38:		Line 38:
	All dev changes to the db will occur in the patch or from the FPR.		All dev changes to the db will occur in the patch or from the FPR.

		+	==Release==
	Updating from 1.0 to 1.1 can run the patch.		Updating from 1.0 to 1.1 can run the patch.