Changes between Version 20 and Version 21 of metadatachanges


Ignore:
Timestamp:
Jan 16, 2012, 5:37:14 AM (12 years ago)
Author:
simonp
Comment:

Include further work on transaction isolation setting and XLINKS

Legend:

Unmodified
Added
Removed
Modified

  • metadatachanges

    v20 v21  
    1111== Overview ==
    1212
    13 There are many use cases where the complete history of changes to a metadata record and its properties (eg. privileges, categories and status) needs to be captured. This proposal adds a local filesystem subversion repository to !GeoNetwork to do this.
     13There are many use cases where the complete history of changes to a metadata record and its properties (eg. privileges, categories and status) needs to be captured. This proposal adds a local filesystem subversion repository to !GeoNetwork and code to capture these changes.
    1414
    1515=== Proposal Type ===
    … …  
    4747
    4848 * auto commit the subversion repository after every change to the metadata record or its properties
    49  * apply the changes to the subversion repository and commit/abort the subversion repository and database at the same time
    50  * set a flag saying that changes have been made and then at commit, query the database and apply changes to the subversion repository   
     49 * apply the changes to the subversion repository as they are made, then commit/abort the subversion repository and database at the same time
     50 * set a flag saying that changes have been made and then at database commit, query the database and commit changes to the subversion repository    
    5151
    5252The first approach is the easiest to code particularly as regards maintaining consistency between the subversion repository and the database: if a database operation fails we don't make any changes to the subversion repository. If any of the subversion repository commits fail, then we could abort the current database commit. 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).
    … …  
    5454The second approach is slightly more difficult to code: subversion changes need to be bundled by keeping the subversion commit editor open and using a listener to commit/ignore 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 eg. as described at http://osdir.com/ml/version-control.subversion.javasvn.user/2007-10/msg00053.html.
    5555
    56 The third approach is the one that has been implemented. The coding is more straightforward than the second approach and only slightly more complex than the first.
     56The third approach is the one that has been implemented. The coding is more straightforward than the second approach, only slightly more complex than the first and it captures the state of both the metadata record and its properties at database commit time.
    5757
    5858To 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:
    5959 * This function ultimately calls the setOperation method in the !DataManager to change the privileges for the metadata in the database.
    6060 * In setOperation we add a call to setHistory in the !SvnManager which records the id of the metadata record against the database channel.
    61  * 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.
    62 
    63 Lastly we should mention that the metadata properties are stored in the subversion repository as XML files. The typical structure of a directory for a metadata record in the repository consists of a directory (named after the id of the metadata record) which contains:
     61 * Just prior to the database channel being 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.
     62
     63Note that the current transaction isolation setting for database connections from the apache database connection pool used in GeoNetwork is read-committed. The transaction level for these connections will need to be set to the more strict serialized transaction isolation level if metadata versioning is config'd on, so that changes made by one transaction to the record and its properties will not overlap with changes committed by another transaction. The transaction isolation level in GeoNetwork used to be serialized before version 2.6. GeoNetwork admins who configure the database pool through JNDI will need to be warned to set the transaction isolation level to serialized in the documentation if they want to use metadata versioning.
     64
     65The metadata properties are stored in the subversion repository as XML files. The typical structure of a directory for a metadata record in the repository consists of a directory (named after the id of the metadata record) which contains:
    6466
    6567 * metadata.xml - a record of changes to the content of the metadata record itself
    … …  
    236238[[Image(versioning2.png)]]
    237239
     240=== XLINKS ===
     241
     242Metadata fragments (from directories local to GeoNetwork or from external URLs on the internet) can be linked into metadata records to support reuse.
     243
     244The current patch will support versioning resolved records only. This means that all metadata fragments (both local and external) will be resolved before the record is versioned.
     245
     246The user will be able to switch on versioning for fragments held in directories in the local GeoNetwork catalog in much the same way as they can for metadata records (see user interface examples above). At the moment, a change made to a local fragment will not force a new version of any record that links this fragment. Instead these changes will be picked up next time the record or its properties are changed.
     247 
     248=== Patch ===
     249
    238250Patch attached to ticket #726
    239251