OLE Change Management TBD
This document describes the mechanics of the database version control process. How the changes get into the master schema must still be decided by the OLE development team.
Process Overview
To manage and track database changes, the Kuali OLE project utilizes Subversion to track the master state of the database at any given point in time. The ole-cfg-dbs project in the Subversion repository is considered the definitive source and is stored as a combination of XML (for database structure) and flat files (for data.)
To make changes to this master SVN project easier, the project also manages a master database schema (OLEDBA). This schema is exported nightly to the ole-cfg-dbs/development path in SVN. This allows changes to be made to the master schema using normal database tools rather than requiring the "DBA" to edit the files in SVN. Any changes made to the schema during the day will be exported by the DB-Export-OLEDBA job in Hudson every night. For this reason, never update the files in the ole-cfg-dbs/development path directly, as they will be overwritten by the state of the OLEDBA schema the next night.
Then, using this SVN project, any of the development or testing databases can be refreshed from that stored definition. In fact, on a daily basis, the OLECI (for unit testing), OLELOCAL (for developers without a local database), and OLEDEV (for the http://dev.ole.kuali.org:8080/ole-dev/ instance) are deleted and restored from this project.
The additional complication to this is that there are actually three components to the full refresh process as will be discussed below.
ole-cfg-dbs Project Structure
- schema.xml
- graphs
- formats
- data
Document TODO Notes
- structure
- data
- DBA schema
- satellite databases
- database refresh
- Rice data
- master schema from Rice project
- OLE Data Overlay
- Liquibase
- Workflow