Resolution: Won't Fix
Affects Version/s: None
Fix Version/s: 0.9.3
KULRICE-3139 Create a new master datasource for 1.0 KC db development KULRICE-12998 Test git with db install process KULRICE-7217 Implement growls processing KULRICE-4923 Implement database compatibility verification process KULRICE-49 Document our process for making core DB changes in Rice KULRICE-13966 Update db install process for branch changes KULRICE-12994 Git Migration KULRICE-2769 Implement a way to indicate whether or not the DocSearchGenerator should attempt to process result sets KULRICE-5595 Create a new KRMS node implementation extending RequestActivationNode KULRICE-9970 Add Hook to DD for processing beans prior to validation
Rice Module:Rice Core
Implement a plan that addresses the following aspects:
- consuming the DB independence work done by KFS (see linked issues)
- re-organization of DDL/SQL files into more consolidated, but module specific ANSI SQL files or Torque XML files???
- do we want our bootstrap DB data to be in a single SQL file or in separate files to line up with each module?
- support for multiple database products (i.e. Oracle, MySQL) and how we support generating and maintaining these in our process
- updating existing DB related documentation - https://test.kuali.org/confluence/display/KULRICE/Database+Change+and+Migration+Policy and https://test.kuali.org/confluence/display/KULRICE/Making+a+Database+Change
- coming out of the box with an embedded DB such as Derby
- how to handle migration scripts and upgrades to the DB between Rice versions - how to generate these and make them part of a better upgrade process
- automatic validation of DB changes against an embedded DB such as Derby
- impact of 0.9.3 refactoring on module specific files
The first step to this task should be to deal with the sub-task for putting a fully detailed plan together that addresses the issues above. Make sure the team has a chance to review and come to agreement on a process to move forward with.