Changes between Version 5 and Version 6 of metadatachanges

Timestamp:

Jan 9, 2012, 5:42:19 AM (13 years ago)

Author:

simonp

Comment:

--

metadatachanges

@@ -42 +42 @@
 Not all records will be tracked as the compute and systems admin cost of this tracking for every record, particularly in larger catalogs is too high. Instead only those records that are edited and updated within the local GeoNetwork instance will be tracked in the subversion repository.
 
-The database will remain the point of truth for GeoNetwork. That is, changes will be tracked in subversion, but the database will continue to be the facility used by the code. For example, although it is possible to extract the latest version of a metadata record from the subversion repository, the code will continue to extract the latest version of the metadata record from the database table.
+The database will remain the point of truth for GeoNetwork. That is, changes will be tracked in subversion, but the database will continue to be the facility used by all services. For example, although it is possible to extract the latest version of a metadata record from the subversion repository, all services will continue to extract the latest version of the metadata record from the database table.
 
-Using a subversion repository in place of database history tables, forces us to think about maintaining both the subversion repository and the database in a consistent manner ie. committing or aborting the database and subversion repository. In developing this proposal we've examined two approaches:
+Using a subversion repository in place of database history tables, forces us to think about maintaining both the subversion repository and the database in a consistent manner ie. committing or aborting the database and subversion repository. In developing this proposal we've examined three approaches:
 
  * auto commit the subversion repository after every change to the metadata record or its properties
- * commit/abort the subversion repository and database at the same time
+ * apply the changes to the subversion repository and commit/abort the subversion repository and database at the same time
+ * set a flag saying that changes have been made and then at commit, query the database and apply changes to the subversion repository   
 
-The first approach is the easiest to code particularly as regards maintaining consistency between the subversion repository and the database: if the database commit fails we can simply avoid committing any changes to the subversion repository. If any of the subversion repository commits fail, then we can abort the database commit as well. However, excepting the simplest operations on a single record and without some possibly substantial changes to the existing code, the changes recorded in the subversion repository will bare little or no resemblance to the changes that are made by !GeoNetwork services. For example, if the user decides to change the privileges on a metadata record, this would result in more than one commit to the subversion repository (in fact the number of commits would be equal to the number of group permissions selected in the privilege interface).
+The first approach is the easiest to code particularly as regards maintaining consistency between the subversion repository and the database: if the database commit fails we can simply avoid committing any changes to the subversion repository. If any of the subversion repository commits fail, then we can abort the database commit as well. However, excepting the simplest operations on a single record, the changes recorded in the subversion repository will bare little or no resemblance to the changes that are made by !GeoNetwork services. For example, if the user decides to change the privileges on a metadata record, this would result in more than one commit to the subversion repository (in fact the number of commits would be equal to the number of group permissions selected in the privilege interface as they are set one by one in the DataManager).
 
-The second approach is more difficult to code: subversion changes need to be bundled by keeping the subversion commit editor open and using a listener to commit/abort the changes to the subversion repository when the database is committed/aborted. This scenario is further complicated by the design of the tmatesoft api which does not allow reentrant calls on a subversion repository object and the fact that the editor cannot open files and directories in the repository more than once as described at http://osdir.com/ml/version-control.subversion.javasvn.user/2007-10/msg00053.html.
+The second approach is more difficult to code: subversion changes need to be bundled by keeping the subversion commit editor open and using a listener to commit/abort the changes to the subversion repository when the database is committed/aborted. This scenario is complicated by the design of the tmatesoft api which does not allow reentrant calls on a subversion repository object and does not allow files and directories in the repository to be opened more than once in a transaction as described at http://osdir.com/ml/version-control.subversion.javasvn.user/2007-10/msg00053.html.
+
+The third approach is the one that has been implemented. The coding is much more straightforward than the second approach and only slightly more complex than the first. 
+
+To illustrate the third approach, let's examine a typical scenario where we wish to capture changes to the privileges of a metadata record made by a user in the 'Set Privileges' function:
+ * This function ultimately calls the setOperation method in the DataManager to change the privileges for the metadata in the database.
+ * In setOperation we have added a call to setHistory in the SvnManager which records the id of the metadata record against the database channel.
+ * When the database channel is committed at the end of the 'Set Privileges' function, the listener on the database channel reads the privileges for the metadata record and commits any changes to the subversion repository.
+
+
 
 === Backwards Compatibility Issues ===