Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-ALPHA2
    • Fix Version/s: 2.0-ALPHA3
    • Component/s: Tools
    • Security Level: All
    • Labels:
      None

      Description

      Currently drop schema infers from the current metadata model which tables have to be dropped.

      However when your schema changes and you then want to regenerate the database the tables may have changed and SQL errors like "table does not exist" may occur.

      Therefore I propose to extend dropSchema() to have four modes:

      • "metadata" - Drop schema of the current metadata model.
      • "force-metadata" - Drop schema of the current metadata model, even if some tables don't exist.
      • "database" - Drop all tables of a database.
      • "orphans" - Drop all tables that are in the database but not in the metadata model.

        Issue Links

          Activity

          Hide
          Benjamin Eberlei added a comment -

          Because of Bug DDC-98 the orphans command is a bit dangerous as of now, but the rest will be implemented for now. There are other problems also with orphans.

          Show
          Benjamin Eberlei added a comment - Because of Bug DDC-98 the orphans command is a bit dangerous as of now, but the rest will be implemented for now. There are other problems also with orphans.
          Hide
          Benjamin Eberlei added a comment -

          This is a bit more complicated because of foreign key constraints.

          The algorithm for "database" should work like the following:

          1. Sort the Database Tables according to the Classes given by CommitOrderCalculator.
          2. List the tables of the database and append the additional tables to the stack.

          Also force can be dropped by first retrieving a list of all the tables of a database and diff'ing the tables to be dropped.

          Show
          Benjamin Eberlei added a comment - This is a bit more complicated because of foreign key constraints. The algorithm for "database" should work like the following: 1. Sort the Database Tables according to the Classes given by CommitOrderCalculator. 2. List the tables of the database and append the additional tables to the stack. Also force can be dropped by first retrieving a list of all the tables of a database and diff'ing the tables to be dropped.
          Hide
          Benjamin Eberlei added a comment -

          Implemented a new mode "database" which drops all tables in the database, first the metadata tables based on commit order calculations, then the missing tables.

          Additionally implemented a filter which deletes tables from the to drop list when they don't exist yet (which is relevant when metadata is changing alot).

          Show
          Benjamin Eberlei added a comment - Implemented a new mode "database" which drops all tables in the database, first the metadata tables based on commit order calculations, then the missing tables. Additionally implemented a filter which deletes tables from the to drop list when they don't exist yet (which is relevant when metadata is changing alot).

            People

            • Assignee:
              Benjamin Eberlei
              Reporter:
              Benjamin Eberlei
            • Votes:
              1 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: