Sometimes it is inevitable that new business requirements come up after the system has gone production and you have to change table structure or even drop/add table from/to schemas. Pervasync supports schema evolution so that you don’t have to re-build the whole system from scratch.
Schema Evolution Steps
Shutdown sync server
Before you make any changes to the system, it is recommended to first shut down sync engine and sync servlet using the web admin console. It is also recommended to sync all the clients before the server shutdown so that all client side changes are uploaded to server.
Alter DB table
Then, you make physical changes to the central database schemas/tables, such as create/drop tables, alter tables to add/remove columns or change column data types.
Update sync table
Go to the web admin console and locate the table you just changed. Delete the sync table if you dropped the corresponding DB table. Update the sync table if you altered the corresponding DB table.
Start sync server
Re-start sync engine and re-open sync servlet using the web admin console.
Propagation of Table Definition to Clients and Table Reload
The first sync after the server schema change will propagate the new schema definition to client. If a sync table was removed, the corresponding client DB table will be dropped. Also in general, if a sync table was updated, the corresponding client DB table will be altered.
Some updates to the sync table would cause the client DB table be dropped, re-created and re-populated with data from server. This is called a re-load.
If you change the subsetting query, clients may be assigned a different sub-set of data. Therefore, Pervasync will do a table re-load for all the clients. Altering a table’s primary key will cause the same.
If you change the values of subsetting parameters for a particular client, that client would get a reload for the affected tables. Other tables and clients won’t get a reload.