Spring Roo
  1. Spring Roo
  2. ROO-1304

Don't default to "drop and create" in the JPA config when using reverese engineering

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.1.0.M3
    • Fix Version/s: 1.1.0.RC1
    • Component/s: PERSISTENCE
    • Labels:
      None

      Description

      Tried the reverse engineering and was a bit surprised that all my existing data disappeared when I started the Roo generated web app. I think it would be better not to default to "drop and create" of the schema in the case of reverse engineering since I'm now using a db first approach and might have some data in my tables already.

        Issue Links

          Activity

          Hide
          Alan Stewart added a comment - - edited

          I agree, however, for those not using DBRE, creating and dropping tables for unit tests which Roo users have been used to may cause issues for them if the behaviour is changed. I view the DBRE tool primarily as a means for prototyping from a schema which is typically controlled by a data modeller and/or a DBA during the design phase where data is not that important.

          In previous companies I've always had a separate test configuration in the src/test/resources tree which is used for unit tests and usually points to a different database whereas the production/UAT schemas are accessed using the src/main/resources tree. I will look into this again, as I know version 2.8 of the maven-eclipse-plugin facilitated this for running unit tests in Eclipse as the src/test tree appeared first in the classpath order, but we are using 2.7 due to an AspectJ issue.

          At worst, I will change the default configuration to use "validate" and document this for users.

          Show
          Alan Stewart added a comment - - edited I agree, however, for those not using DBRE, creating and dropping tables for unit tests which Roo users have been used to may cause issues for them if the behaviour is changed. I view the DBRE tool primarily as a means for prototyping from a schema which is typically controlled by a data modeller and/or a DBA during the design phase where data is not that important. In previous companies I've always had a separate test configuration in the src/test/resources tree which is used for unit tests and usually points to a different database whereas the production/UAT schemas are accessed using the src/main/resources tree. I will look into this again, as I know version 2.8 of the maven-eclipse-plugin facilitated this for running unit tests in Eclipse as the src/test tree appeared first in the classpath order, but we are using 2.7 due to an AspectJ issue. At worst, I will change the default configuration to use "validate" and document this for users.
          Hide
          Alan Stewart added a comment -

          For each ORM provider the appropriate property is changed so that tables are not created or dropped the first time the database reverse engineer command is run. Fixed in Git ID 75cc3bc4c00f5a75d156d2c4f2316bf7ade5c5f4

          Show
          Alan Stewart added a comment - For each ORM provider the appropriate property is changed so that tables are not created or dropped the first time the database reverse engineer command is run. Fixed in Git ID 75cc3bc4c00f5a75d156d2c4f2316bf7ade5c5f4

            People

            • Assignee:
              Alan Stewart
              Reporter:
              Thomas Risberg
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: