Small enhancement: make differences reported by the "-t TEST" option's output easier to identify by adding a line prefix

[simonpane]

Small Enhancement Suggestion:

When running using the --type TEST option, the resulting output can be long when there are a large number of tables to compare. Consequently, the output is usually written to a log file -- or as redirection to a file from STDOUT.

Searching through a long log file of output and finding all reported differences between the Oracle source database and the PostgreSQL target database can be a time consuming, manual effort. Usually involving searching for the "[ERRORS \<object type> COUNT]" sections and then manually capturing the subsequent lines.

An enhancement to make processing of differences more efficient would be to simply prefix the difference message with some prefix text. Such as the word FINDING:.

Such a change is as simple as changing one line in the Ora2Pg.pm file:

    print "[ERRORS \U$lbl_type\E COUNT]\n";
    if ($#errors >= 0)
    {
        foreach my $msg (@errors) {
            print "$msg\n";
        }
    }

To something like:

    print "[ERRORS \U$lbl_type\E COUNT]\n";
    if ($#errors >= 0)
    {
        foreach my $msg (@errors) {
            print "FINDING $msg\n";
        }
    }

Then the output is more usable as just the findings (or "differences") can be easily extracted from the log file with a simple command such as:

grep ^FINDING TEST.out

Example usage:

$ grep ^FINDING TEST.out
FINDING: Table scott.t4 doesn't have the same number of indexes in source database (1) and in PostgreSQL (2).
FINDING: Table scott.dept doesn't have the same number of unique constraints in source database (0) and in PostgreSQL (1).
FINDING: Table scott.emp doesn't have the same number of unique constraints in source database (0) and in PostgreSQL (1).
FINDING: Table scott.supplier3 doesn't have the same number of unique constraints in source database (1) and in PostgreSQL (2).
FINDING: Table scott.t3 doesn't have the same number of not null constraints in source database (2) and in PostgreSQL (1).
FINDING: Table scott.t4 doesn't have the same number of not null constraints in source database (4) and in PostgreSQL (2).

[simonpane]

Note that simply grepping for ^Table is not always sufficient as the error finding is sometimes related to a different object type such as a view.

Pull Request #1628 simply adds a searchable keyword via a one-line change.

[simonpane]

Closing as this enhancement has been merged.