1.6.3492 - December 04 2019

New Features

• We now provide a UI for creating an initial baseline script in the wizard and on the "Generate migrations" tab for existing empty projects.

Improvements

• The table in the "Apply to database" tab now allows sorting on all columns.
• The "Apply to database" tab now has a new column which shows the order the scripts will be run in.
• The database change notification now works in scripts source mode.

Changes

• The default flyway table name for new projects is now "redgate_schema_history".

Fixes

• Quote marks are now stripped from repeatable migration file names. This fixes an issue where repeatable migrations for programmable objects would not be saved correctly

1.5.3350 - November 26 2019

New Features

• Scripts source mode and single shadow schema mode can now be used together.

To enable scripts source mode, specify redgate.experimental.scriptsSource=<path to scripts folder>. There is no longer a need to remove the flyway.url parameter as redgate.experimental.scriptsSource will take precedence if set. To enable single shadow schema mode, specify redgate.experimental.shadowSchema. Either flyway.url or redgate.shadowUrl must be set and redgate.shadowUrl will take precedence.

Changes

• The comparison no longer refreshes automatically in the background. An * is displayed on the refresh button if there are new changes to the development database when require a refresh to identify.
• Changes to user privileges are now ignored.

Improvements

• The redgate.experimental.scriptsSource configuration parameter can now be a relative path.
• Updates the displayed icons when in scripts source mode.
• A message suggesting the database be baselined is shown when given a project with no existing migrations.

Fixes

• Fixed an issue where the tool attempted to validate the source database when in scripts source mode.
• Fixed an issue where details of a validation failure would not be displayed when in scripts source mode.
• Fixed an issue where an additional menu bar was shown in the application.

1.4.3214 - November 20 2019

New Features

We've introduced a new experimental "scripts source" mode which may reduce how often a shadow database is required.

The scripts source acts as an alternative to the development database and is a directory on disk that contains the SQL script files that represent your database.
These scripts can be generated and maintained using Source Control for Oracle and can also be source-controlled.

When in this mode, Redgate Change Control will help you generate migrations scripts from changes that have been pushed to your scripts folder rather than directly from changes made to your database.
Depending on your setup, this might mean that fewer people ever need to have access to a shadow database.

Additionally, the shadow database will need to be accessed only to generate migration scripts - you can make changes to your database, save them and source-control without any need for a shadow.

How to use:

To enable this mode in a project, remove or comment out the flyway.url setting and specify redgate.experimental.scriptsSource=<path to scripts folder>.

Once enabled, use Source Control for Oracle to manage the scripts folder while making changes to your database. You can then use Redgate Change Control to generate migration scripts from the scripts folder.

It is worth noting that at this stage, this mode cannot be used in conjunction with the experimental "Single Schema" mode introduced in the previous release.
We anticipate that these two modes will likely work together in a future release.

Improvements

• Improved validation messages when loading projects
• Added a help widget explaining programmable objects
• The app now shows a validation error and prevents new scripts from being generated if flyway detects a validation problem (eg applied scripts not resolved in project files)

1.3.3074 - November 11 2019

New Features

We've introduced a new experimental "single schema" mode which may replace the need for a separate shadow database in some cases:

As the name suggests, this mode only works when the flyway project covers a single schema. A second schema is required to act as the shadow when generating migration scripts. To enable this mode in a project, remove or comment out the redgate.shadowUrl setting and specify redgate.experimental.shadowSchema=<second schema>:

flyway.schemas=HR
redgate.experimental.shadowSchema=HR_SHADOW

There are a couple of caveats when writing migration scripts in this mode:

• Any references to objects in the managed schema must not be schema-qualified. Since the migration scripts will run against different schemas with different names, managed objects must always be created in the current default schema.
• Any references to objects in other schemas must still be schema-qualified. You'll be responsible for making sure any dependencies of the managed schema are present in the database as appropriate.

For example:

CREATE TABLE log (
message VARCHAR2(50),
timestamp INTEGER
);

-- this object references log in the same schema, so log must not be schema-qualified
CREATE OR REPLACE TRIGGER SetTimestampForLog BEFORE INSERT ON log
FOR EACH ROW
DECLARE
v_today DATE;
BEGIN
SELECT CURRENT_DATE INTO v_today FROM DUAL;

-- date2epoch is in a different schema, so must be schema-qualified
:new.timestamp := util.date2epoch(v_today);
END;

We're looking into other alternatives around reducing the need for a shadow database, so stay tuned!

Improvements

• Improved handing of dependencies between stateful and programmable objects in the generated migrations

Fixes

• Spaces are now allowed in the migration file name when editing generated scripts
• Fixed an issue which would delay the comparison results being displayed while column ordering preferences were being loaded.
• Fixed an issue were selecting changes in the comparison results would set focus to the first change in the list

1.2.2861 - October 31st, 2019

Improvements

• Persist the sort order of the comparison differences table across page reloads and application restarts.
• Added logging to help debug errors loading project settings

Fixes

• Fixed an issue where the database name was not being shown in the header bar when connecting with a JDBC url without '//' before the hostname.
• Fixed an issue where the application would sometimes render a blank screen on error.
• Fixed an issue where the UI would occasionally freeze.
• Fixed an issue where the Apply to Database button was not disabled when there was a project validation error.

1.1.2816 - October 29th, 2019

Improvements

• Prevent sorting of the comparison differences table by the checkbox column.
• Improve the UX for displaying unhandled errors.
• Prevent the resetting of comparison difference selections after the page refreshes.
• Automatically trigger a refresh of the database comparison after successfully applying migrations.
• Now displays a repair banner if validating the project fails.

Changes

• Folders created on disk for Repeatable Migrations are now pluralised.

Fixes

• Fixed an issue where attempting to update the product after closing the application sometimes failed.
• Fixed an issue where a valid Oracle JDBC (version 19.3) connection string was not correctly parsed.
• Fixes an issue where the number of comparison differences displayed in the header bar after generating scripts was incorrect.
• Fixed an issue where an error would occur if the repair banner was shown but there were no failed migrations.
• Fixed an issue where script properties were being written to the log file.
• Fixed an issue where writing to the log file errored unexpectedly.
• Fixed an issue where duplicate error boxes could be shown.
• Fixed an issue where incorrect credentials were used to connect to the shadow database.
• Fixed a UI issue where the progress bar was incorrectly displayed.

1.0.2702 - October 23rd, 2019

Features

• Update your development database using the migration scripts in a flyway project

• Generate your next Flyway migration script based on changes made to your development database