All,
I'd like to start getting some eyes on the pgsql branch in preparation of a
merge to
master. So far, the changes on this branch have been focused on porting the
schema and
updating the application infrastructure to work with both oracle and postgres
databases.
None of the queries have been ported/forked yet. I'm not implying that the branch is
ready to merge to master as is. Rather, that it is ready for review and I'd like
everyone's help to get it to where we can merge it.
Here is a summary of the changes to look for (as best I can):
SCHEMA DIRECTORY
The goal here was to push as much of the schema into common as practical and
make
the schema code tree as developer friendly as possible.
- The schema directory has been refactored replacing
rhnsat/
with:
oracle/
postgres/.
- Forked (cannot be common) items:
rhnsat/class/
rhnsat/types/
rhnsat/procs/
rhnsat/packages/
(git) moved to oracle/ and copied to postgres/ and ported to PG.
- Table files (rhnsat/tables/*)
- <table>.sql files:
- Most moved to common/tables/
- Trigger DDL split out and moved into existing or new
oracle/triggers/<table>.sql
- *_triggers.sql files:
- (git) moved to oracle/triggers/
- _triggers suffix removed because redundant w/ directory scoping.
- *_data.sql files:
- Most (git) moved to common/data/
- Few files forked and (git) moved to oracle/data. Forked files copied to
postgres/data and ported to PG.
- _data suffix removed because redundant w/ directory scoping.
- *_index.sql files consolidated into file w/ table DDL. Most of the indexes
were already there anyway.
- View files:
- Most view (.sql) files were (git) moved to common/views. This involved
some standardizing of the view SQL but most were unchanged.
- Few view (.sql) files were forked:
- (git) moved to oracle/views/
- Copied to postgres/views and ported to PG.
- Upgrades (upgrade/* directories & files):
- Most files (git) moved to common/upgrade/<upgrade>
- Few files forked: (git) moved to oracle/upgrade/<upgrade>.
- Few files forked: copied to postgres/upgrade/<upgrade> and ported to PG.
- Upgrade scripts containing updated things created as CREATE OR REPLACE like
views
procs and packages updated replacing cut-n-paste content that is redundant
with
install files with an include to the install (.sql) file. See examples in
git tree.
- So far, git only has 0.4 -> 0.5 (example) upgrade scripts, rest to follow.
COMMON --> DB SPECIFIC
At build, common (common/) files are transformed by a build tool named
"chameleon" into DB
specific files. For example:
#
# cd oracle
# chameleon -s oracle -o tables/common/x.sql ../common/tables/x.sql
#
Long term, chameleon will be a Fedora project and included in Fedora
distribution.
For now, it is available on the wiki:
https://fedorahosted.org/spacewalk/wiki/PostgreSqlProject#Attachments.
STYLE
You may notice that the common/tables/*.sql were formatted using chameleon.
Consistent with most DDL/SQL style guides, chameleon renders keywords in caps
and
uses spaces instead of tabs. If you don't like this style, don't freak out. We
take a vote and I can easily re-run the files through chameleon and reformat to
any style we like :-)
MAKEFILES
The Makefile.schema refactored into a /regular/ makefile. Dependency sorting
and .sql
file aggregation split out into a build tool named "blend". Although, make
does do
dependency sorting with the .deps files, the Makefile.schema (although, a clever
application of the technology) seems to exceed make's intended use and was
difficult to
maintain and debug. Blend also provides analysis of .deps files and reports
unused
rules, unfound references, duplicate files and circular dependencies. Anyway,
if someone
really believes we should go back to using make for this, I suppose we can.
PACKAGING
The spacewalk-schema.spec was updated to package and install install / upgrade
scripts for
both oracle and postgres. The files are installed in:
/etc/sysconif/rhn/oracle/
main.sql
spacewalk_0.4-spacewalk_0.5.sql
...
/etc/sysconif/rhn/postgres/
main.sql
spacewalk_0.4-spacewalk_0.5.sql
...
As you can see, the upgrade scripts are aggregated using blend just like the
install
scripts. Spacewalk::Setup and the spacewalk-schema-upgrade scripts need to be
updated to
support the new directory structure and files names. This work has been
started but still
needs more work. ** Milan, can you help with changes to
spacewalk-schema-upgrade? Also,
anyone know what the links are for in the upgrade directories? Do we need
them? Can they
be created during RPM install?
INSTALL / SETUP
- Installer
- Isolated more Oracle specific parts of spacewalk-setup.
- Added concept of specifying a database "backend" to use.
- Changes to support both Oracle/PostgreSQL db connection strings.
- Changes to support schema installation for both db's from new
schema location.
- rhn.conf now gets full db connection params instead of just a dsn
- not all are used for Oracle
- command line and db population scripts modified to populate schema
for both databases (some used --dsn argument, no longer valid)
- Python backend:
- More work on rhnSQL to support both databases transparently.
- added Cursor.update_blob method to support both methods of updating
blobs/byteas.
- Added support for calling PostgreSQL stored procedures (still needs
work)
- General code cleanup in rhnSQL.
- Needs heavy testing.
- Many query changes to progress through setup on both dbs.
- - Perl stack:
- Prepped for connecting to both databases.
- Heavy changes to how connections are established, stored, and
re-used. (mostly in a3ea30ad5badd272250ad7230305d1b9c2a96db2)
- Java
- Added dependency on postgresql jdbc driver.
- Initial changes to support connections to both dbs, had some
success with this, got to user creation screen with a couple hacks
during setup.
_______________________________________________
Spacewalk-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/spacewalk-devel
