Application of subversion configuration and management in Java enterprise projects

The most important asset of an enterprise should be data information, but today's enterprise applications, in addition to the need to store data, often require the tracking of data changes throughout the process, and will extend to a series of related requirements, such as the cause of the data change, the time of change, and in many cases is the document stored in the form of data tracking. Using subversion can satisfy these seemingly mundane but actually complex requirements.

Challenges from the data

Enterprise applications store critical data, and applications are not limited to inserting, reading, updating, and deleting data (that is, crud), and applications expect to be able to store the history of data changes. In addition, the enterprise is required to store the history of the changes in the data assets, in accordance with a set of business or mandated requirements, and to require the storage of who, at what time, for what reason, how to change the data and so on.

The format and size of the application data also have many variables, including simple data, such as strings and numbers, and complex types, such as storing documents using BLOBs or CBLOB types. A typical application handles a large amount of data stored in a document that is uploaded to the program, and it is a nightmare to track changes in documents such as complex types using traditional history tables.

Using history tables for tracking

Relational databases are the first choice to store data, efficiently organize, store, and retrieve data information, and because applications store data in relational databases, it's logical to try to store historical trace data, typically using a timestamp data table to hold all the important data tables. When you update the primary table, you push the old data into the history table, which is typically done by triggers or by the application itself.

Using the history table to store historical information, the following issues occur:

relational databases and relational models improve the efficiency of data storage and retrieval, but historical tables are clearly not appropriate for using relational databases.

. The database does not support version control. Applications have to use triggers or other custom techniques to store data carefully (to achieve versioning).

It is important for the application to detect changes between versions and retrieve historical data from historical tables to compare with each other.

Relational databases are still warehouses for storing and retrieving business data, and they are good at managing data. The disadvantages listed above are limited to using the relational data model to store multiple versions of data and to track historical data.

Subversion and JAVASVN

Subversion is a version control system that can replace CVS (a traditional version control system). Subversion uses a tree-like structure called a warehouse to store files and directories. Subversion tracks all changes to information in the warehouse, which has a central repository that allows concurrent updates, allows access to the warehouse via HTTP or HTTPS, and avoids firewall interference during use. The idea of subversion is "copy-edit-merge", which means that you do not need to lock the modified object when you modify it.

(Translator note: For WebDAV, the abbreviation for web-based Distributed Authoring and Versioning is an extension of a standard HTTP protocol that uses web technology to share read and write directories and files as readable objects. Turn the web into a read-write medium. RFCs2518 and 3253 describe the Webdav/deltav for HTTP extensions, URL http://www.webdav.org/. ）

JAVASVN is a pure Java Subversion Client class library that provides a Java program-based application Interface (API) that interacts with subversion, and JAVASVN provides the underlying interface for directly reading a subversion repository, Also provides a high-level interface to check out a working copy from a subversion warehouse.

Now that applications can meet the needs of data storage and change tracking in a way that combines relational databases with subversion, updates to the database will also commit changes to subversion, which will be the primary source of data for record changes, Relational databases are used in addition to all other storage. This also has an advantage because Subversion uses copy-edit-merge mode, so that it is no longer required to lock the target table every time the data is retrieved from the relational database.

Example Learning

Let's now identify the problems and solutions to be addressed, and use examples to illustrate how subversion and javasvn are used. We use JAVASVN to store a simple domain object in Subversion, retrieve previous versions, and display differences for two versions. The domain object of our example is the loan data shown below. The "Resources" section at the end of this article has a complete source code link.

public class LoanData extends BaseTrackingObject {
　　　　 private String loanId;
　　　　 private double loanAmount;
　　　　 private float　loanRate;
　　　　 private int　　loanTerm;
　　　　 ......
　　　　 ......
}

Here, the abstract Basetrackingobject class is used to define common tracking data, such as modifying the user, modifying the date, modifying the reason, and so on. It defines the settings and obtains the Objectid abstract method, uses it as the primary key to access the domain object, defines a tool method named Getxmlrepresentation to convert the object to XML format, and then to store and retrieve the data in subversion.