All,
The outcome of the meeting yesterday regarding the pgsql branch review is as
follows:
After lengthy discussion it was decided (almost unanimously by attendance) that
the work
on the pgsql branch would be merged to master without refactoring the commits.
There
was general agreement that the concerns and objections raised about doing this
had a lot
of merit. However, they did not justify the effort required to re-implement
work that has
already been completed.
Pending resolution of the following content related comments and assuming no
new issues
are raised, the branch will be merged to master. Merge vs cherry pick, not
sure which is
best. Thoughts anyone?
Content related concerns to be addressed before merging pgsql to master:
* Trailing white space needs to be removed.
I will trim the trailing white spaces.
* Packaging of upgrade scripts needs to be resolved.
I committed a change to pgsql branch that will *undo* the proposed changes
to the packaging and installation of the upgrade scripts. They will be
installed
in same place and have the same form as before. This means that initially,
upgrades will only be for oracle installs. After the dust settles on the
merge
to master we will revisit the upgrades.
* Replacing the named NOT NULL constraints in the common tables (.sql) files
with simple NOT NULL keywords.
- Concern about the upgrade scripts.
Using "ALTER TABLE <table> MODIFY <column> NULL;"
instead of:
"ALTER TABLE <table> DROP CONSTRAINT <constraint name>;" to make a column
nullable in all future upgrade scripts will handle this.
- The change causes problems in the upgrade verification scripts because the
named NOT NULL constraints will be squawked as missing.
Unfortunately, when looking at user_constraints, the constraint_type=R
is for both CHECK constraints and NOT NULL constraints. But, the
search_condition
can easily be used to ignore NOT NULL constraints. Validation that the
column is
NOT NULL, can be done by matching the nullable column in user_tab_columns
when
validating a table's columns. I believe the effort to tweak the upgrade
validation
scripts will be much less then reworking the common tables (.sql) files to
restore
the named NOT NULL constraints.
* Did I miss anything?
Testing before merge to master:
* Get a clean validation report from the upgrade validation script(s) to
validate
the equivalence between a DB created from master install and a DB
created installed from pgsql.
* Run automated testing on spacewalk installed from pgsql. Can this be done?
* Other suggestions?
_______________________________________________
Spacewalk-devel mailing list
Spacewalk-devel@redhat.com
https://www.redhat.com/mailman/listinfo/spacewalk-devel
