Page History

...

1. Make changes to your local database during development.  The changes should follow the standards listed above.
2. Create alter scripts (in Oracle & MySQL DDL) in the appropriate directory for the version you are working on.

   1. All SQL database changes go in a subfolder of db/sql/src/main/resources/org/kuali/rice/rice-sql/upgrades/<x.x.x>

   2. Oracle changes go in the subfolder oracle and MySQL changes go in the subfolder mysql.
   3. Client-side changes should be put in the subfolder client while the rest of the changes should go into server.  There is no need to duplicate scripts between client and server side, the client scripts are applied to the server database automatically (in other words the server schema and dataset is a superset of the client).
   4. Scripts should be further split between bootstrap, demo, and test.
      
      1. If the change is needed by all Rice users to use the system, put it in bootstrap.
      2. If the change is just needed by Rice developers to test something in the system, put it in demo.
      3. If the change is needed by all the unit tests, put it in test.
   5. Scripts should be named with the year, month and day and the JIRA number as such: yyyy-mm-dd--KULRICE-0000.sql.
   6. Both types of scripts should use the / delimiter (as previously only used in Oracle).
3. Create XML ingestion scripts in the appropriate directory for the version you are working on.
   1. All XML database changes go in a subfolder of db/xml/src/main/resources/org/kuali/rice/rice-xml/upgrades/<x.x.x>
   2. Scripts should be further split between bootstrap, demo, and test.
      
      1. If the change is needed by all Rice users to use the system, put it in bootstrap.
      2. If the change is just needed by Rice developers to test something in the system, put it in demo.
      3. If the change is needed by all the unit tests, put it in test.
   3. Scripts should be named with the same value as the XML document <name>

   4. If there is a parent/child relationship, then the child document should go into a folder named after the parent document so that it is ingested after its parent.  This structure can be as deep as needed.

      No Format
      demo |-- ParentDocument.xml |-- ParentDocument |-- ChildDocument.xml

4. Prior to committing any SQL changes reset your local database using the same process CI will use once the SQL has been committed

   1. From the root of a local checkout of the Rice project

      No Format
      cd db/sql mvn clean install mvn initialize -Pdb,local <-- This runs against MySQL mvn initialize -Pdb,local,oracle <-- This runs against Oracle

      
      

   2. The MySQL process connects as “root” (no password) to “ jdbc:mysql://localhost” 

      (you can override the these by adding -D parameters/values for mysql.dba.username, mysql.dba.password & mysql.dba.url)

   3. The Oracle process connects as “system/manager” to “ jdbc:oracle:thin:@localhost:1521:XE” 

      (you can override the these by adding -D parameters/values for oracle.dba.username, oracle.dba.password & oracle.dba.url)

   4. Examine your local database to ensure the changes have been picked up correctly
   5. Perform unit testing / smoke testing of the application as appropriate
5. Prior to committing any XML changes ingest your documents to make sure they work
   
6. Commit your changes.  
7. Start the CI process rice-<x.x.x>-db-install to produce the export. 
   
   1. If it goes red, there is probably a problem with your script.  Check the output and either try to repair it yourself or ask your DM for help.
   2. If it finishes green, then your export is ready to be reviewed on the master-db-install branch of the kuali-devops/rice repository.
8. Double check that the changes you made are correct in the export (see master-db-install branch. Checkout the branch and run impex locally to build the rice database. (Note that the job changes the OBJ_ID value. That's ok).
9. Create pull request to merge the master-db-install branch changes into the code base.  Delete the master-db-install branch after the merger.

...