Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 542662

Summary: Investigate an alternative solution for commit 9bfcee416f62ec342d249c51b8edc64d57b67ef6
Product: [Community] Spacewalk Reporter: Milan Zázrivec <mzazrivec>
Component: ServerAssignee: Jan Pazdziora (Red Hat) <jpazdziora>
Status: CLOSED NEXTRELEASE QA Contact: Red Hat Satellite QA List <satqe-list>
Severity: medium Docs Contact:
Priority: low    
Version: 0.7CC: jpazdziora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: spacewalk-schema-1.1.22-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-07-28 11:50:11 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 585232    

Description Milan Zázrivec 2009-11-30 13:39:06 UTC
Description of problem:
The goal of this bug report is to track efforts leading to an alternative
solution for the problem addressed with commit
9bfcee416f62ec342d249c51b8edc64d57b67ef6 (which was reverted before Spacewalk
0.7).

There were several reasons for the revert:

1) the schema upgrade script won't work. Oracle will throw
"ORA-01440: column to be modified must be empty to decrease precision or scale"
in most of the upgrade situations (i.e. with filled tables)

2) it would be more desirable to change the type of referenced columns
from NUMBER(12) to NUMBER to stay consistent. The upgrade script modifying
NUMBER(12) to NUMBER would work without any problems then.

Version-Release number of selected component (if applicable):
spacewalk-schema-0.7.6-1.el5

Comment 1 Jan Pazdziora (Red Hat) 2010-07-28 11:50:11 UTC
I feel I've addressed this with commit d3b43e0c01de18c7e4cc086804040e83784ccfc6 which reverted the number(12) to number, for all columns connected via foreign keys (so that PostgreSQL is happy).