Compare Schemas treatment of table dependents

Howdy!

In 12.6.0.20b, I’m comparing two schemas on only Tables, Indexes, and Constraints. I need to rework the output in order to give it to the Devs because it’s not how they see the tables from the application that generates them. No biggie.

But as I’m going through this exercise, I’m wondering (now, virtually aloud) if the treatment of table columns is inconsistent. It’s not a selectable option, instead falling invisibly (and correctly, IMHO) under the “Tables” type. But when a column doesn’t exist in either target or source, it’s treated as not existing instead of a table difference. Logically, I think of the new column as a table diff, since it’s a difference in the table structure, and not the missing existence of a true object type (e.g. as defined in the script of the DBA_OBJECTS view for the OBJECT_TYPE column).

Possibly related, there are no column differences reported if a table exists in only the target or source. Could it be an option to not report missing indexes and constraints if the table also does not exist to keep this consistent with the column treatment? I imagine that it could hose up the resulting sync script, which is why I’m wondering if this is a good idea. Personally, I only use the diffs report, as our object generation is handled by the ERP app that uses them.

It’s very possible that my brain has been warped slowly and subtly over time and that I’m not seeing the error of my current vision. Feel free to gently smack me upside the head with a clean rolling pin…gently

TIA!
Rich

Hey Rich,

It’s been a while since I’ve been in this part of the code, but all I can say about the way columns are presented is “it’s been that way forever”, and you’re right, maybe it should change. This is not the first time this has come up.

You make a good point about indexes and constraints.

It’s a little late for this now (this is a short release cycle) but this would be a good project for the next version.

-John