The staging server uses a delta data capturing function to determine which database data changed and should be propagated to the production server. This function is used internally by the staging server, and no manual intervention is required to use it. The delta data capturing function and it's ability to identify changes in the staging database is a major advantage over a simple test server.
The delta data capturing function does not capture all changed data on the staging server:
- The staging server does not cover the files in the delta data capturing and the data moving. So the user has to manually copy the files between the staging server and the production server.
- The staging server does not cover all data in the database. It only covers the content data, not the transactional data.
The content data is the static data asset that is fully controlled by the administrator, such as currency, language, product, catalog, access control, and etc. And we call the tables that have the content data the staging tables. Triggers on every staging table, activated when any of these tables are changed, written to STAGLOG table which is read by the stagingprop command
The transactional data is the data that generated or updated by the shopper's transactions, such as order, inventory, user registration, and etc.
The data capturing function is consist of two parts, the staging triggers and the STAGLOG table.
Three staging triggers are created on each staging table to capture the INSERT, UPDATE and DELETE actions on the staging table. For the staging server trigger sample, see Staging Trigger Example.
Those staging triggers will log the data changes that happen on the staging tables to the STAGLOG table. With the information in the STAGLOG, the staging utility command can propagate the delta data from the staging database to the production database.