Bug 126036 - cms_user_home_folder_map.section_id joined to different data type in content_sections.section_id
cms_user_home_folder_map.section_id joined to different data type in content_...
Product: Red Hat Enterprise CMS
Classification: Retired
Component: other (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: ccm-bugs-list
Jon Orris
Depends On:
  Show dependency treegraph
Reported: 2004-06-15 10:36 EDT by Brett Prucha
Modified: 2007-04-18 13:08 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-05 13:55:01 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Brett Prucha 2004-06-15 10:36:06 EDT
Description of problem:

The DDL creates cms_user_home_folder_map.section_id as a NUMERIC data 
type because of the property:

BigDecimal sectionID = cms_user_home_folder_map.section_id;

Because no type is defined the BigDeciamlAd adapter resolves the type 
to NUMERIC.  The join on cms_user_home_folder_map.section_id however 
references content_sections.section_id which gets resolved to the 
INTEGER data type.

SQL Server does not like to mix data types when referencing foreign 
keys.  I could just create a SQL Server specific PDL for this but I 
also don't think it's a good idea to reference different data types 
together.  Maybe in Oracle and Postgresql NUMERIC and INTEGER are the 
same data type or NUMERIC is smaller than INTEGER.  But in Sql Server 
NUMERIC is defined as -10^38 +1 through 10^38 –1 and INTEGER is 
defined as 2^31 (-2,147,483,648) through 2^31 - 1 (2,147,483,647).  
If the same is true for Oracle and Postgresql then you have a larger 
value trying to match up with a smaller value which in very rare 
cases (id > 10^38 –1) can result in you not being able to create the 
Comment 1 Brett Prucha 2004-06-15 10:45:55 EDT
Sorry, I got that backwards.  Since the primary key is an INTEGER 
it's ok to join them this way.  You can always create the 
relationship.  But I still don't think it's a good idea (:
Comment 2 Jon Orris 2006-09-05 13:55:01 EDT
Closing old tickets

Note You need to log in before you can comment on or make changes to this bug.