Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-3767

Develop Procedure for preventing conflicts between Kuali project Rice data

    Details

    • Type: Task Task
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0.1, KFS Release 3.0
    • Fix Version/s: Not version specific
    • Component/s: Analysis
    • Labels:
      None
    • Similar issues:
      KULRICE-4064Come up with a way to prevent or handle spring bean name conflicts
      KULRICE-4106KFS client dataset missing data for Rice 1.0-kc branch
      KULRICE-1444Develop and document a service naming standard for Rice modules
      KULRICE-4930Align SNAPSHOT release version numbers between various Rice Build artifacts
      KULRICE-6399Make configuring the reloading data dictionary easier for client app developers
      KULRICE-3475for client app db imports, rice dbs project needs to be checked out under the client app dir to avoid scheduling conflicts
      KULRICE-13989Review and release kuali-common and kuali-core
      KULRICE-4654Eclipse validators fail dramatically on Kuali Rice project
      KULRICE-1114remove kuali_application.css and kuali_overrides.css from the rice template project
      KULRICE-4971DataDictionaryIndex currently indexes based on "simple" class name which can result in silent conflicts in DD classes
    • Rice Module:
      KEW, KIM
    • Application Requirement:
      KFS, Rice

      Description

      I was attempting to make a set of SQL scripts from the RICEKULCLI101DBA KIM data that I could apply against a standalone rice server. (dataset extracted from the 1.0.1 server distribution) However, changes in the data caused some inserts to fail.

      It seems that some records in the database were altered at some point (after the schemas were split) such that (in a couple cases) the OBJ_ID is not unique within a table. We also now have overlaps in the primary keys of some of the dependent data records. (attribute data IDs /resp-action IDs, etc...) I think we are going to have to come up with a new pattern or assigned ranges for IDs for project-delivered data. It's only going to get worse the more projects we include in this master Rice schema.

      For UCD, on the tables with problems, I altered the ID column to prefix the values with KFS and changed the OBJ_ID to the same as the PK to get it working.

      One option will be to (as previously discussed) create an XML format for KIM data import/export, but deployments are starting before that tool has been developed and tested.

      For reference, I've attached a set of SQL scripts which I run to pull the data from the Rice kuali client database into a set of standalone scripts.

        Activity

        Hide
        Jessica Coltrin (Inactive) added a comment -

        Assigning to Jeff since I think the Liquibase contexts will be able to resolve this.

        Show
        Jessica Coltrin (Inactive) added a comment - Assigning to Jeff since I think the Liquibase contexts will be able to resolve this.
        Hide
        Jessica Coltrin (Inactive) added a comment -

        Kristina - do the changes you made recently with the data resolve this issue?

        Show
        Jessica Coltrin (Inactive) added a comment - Kristina - do the changes you made recently with the data resolve this issue?
        Hide
        Kristina Taylor (Inactive) added a comment -

        The changes we made recently would resolve the OBJ_ID and duplicate ID failure since we run our release scripts every time we create a database. Any duplicate there would fail before a release. As for the conflicts with other projects, the KR prefix would resolve that. We don't have a process to check that, but that may be up to the person finalizing the release to check.

        Show
        Kristina Taylor (Inactive) added a comment - The changes we made recently would resolve the OBJ_ID and duplicate ID failure since we run our release scripts every time we create a database. Any duplicate there would fail before a release. As for the conflicts with other projects, the KR prefix would resolve that. We don't have a process to check that, but that may be up to the person finalizing the release to check.
        Hide
        Kristina Taylor (Inactive) added a comment -

        Resolving as we have determined that this should no longer happen any more with the new database process. Please reopen if this is not the case.

        Show
        Kristina Taylor (Inactive) added a comment - Resolving as we have determined that this should no longer happen any more with the new database process. Please reopen if this is not the case.

          People

          • Assignee:
            Kristina Taylor (Inactive)
            Reporter:
            Jonathan Keller
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Structure Helper Panel