This document helps developers work with Grouper DDL. If you work with Grouper DDL, please keep this document up to date.
The first thing to know about is the grouper_ddl table. This has one entry for each ddl type. A ddl type means database objects with a certain prefix (e.g. the grouper one starts with grouper_, the default subject one starts with subject, and the organization management one starts with grouperorgs_). On startup, grouper will see if the version in the DB matches the version in the jar (an enum). If not, an error will be logged, and optionally grouper will try to auto-upgrade in 2.5 or print out a script to run if not auto-ddl.
Each version of grouper that changes DDL should have its own class. See GrouperDdl2_5.java for an example
Each object that is changed should be in its own method. Check to make sure if it has been done before. See if it should even run. There are a few cases
|New table||Check if going to current version of above||This is not that important since it is only called from current version|
|New column,view, comment, index, foreign key, etc||Check if going to current version of above||This is important since the method is called from two places, |
This is complicated and requires multiple steps (example in 2.5)
|If you dont create the view with temp name in previous version, then ddlutils wont detect that it needs to drop it|
building from scratch:
|Update statement||Check to see if needs to update||You can check by version number or see if you can find the table in the object model (isTableNew)|