Bug 528214 - ORA-12899: value too large for column "RHNPACKAGECHANGELOG"."TEXT" (actual: 3004, maximum: 3000)
Summary: ORA-12899: value too large for column "RHNPACKAGECHANGELOG"."TEXT" (actual: 3...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Spacewalk
Classification: Community
Component: Server
Version: 0.6
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Michael Mráka
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Depends On:
Blocks: space08
TreeView+ depends on / blocked
 
Reported: 2009-10-09 19:55 UTC by Joshua Roys
Modified: 2010-02-16 12:59 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-02-16 12:56:17 UTC
Embargoed:


Attachments (Terms of Use)

Description Joshua Roys 2009-10-09 19:55:31 UTC
Description of problem:
This happened during a reposync of rhel5 content, specifically setroubleshoot-2.0.5-5.el5-0.noarch.  It looks as if the offending text is in the section of the changelog titled:
* Mon Sep 24 2007 John Dennis <jdennis> - 1.10.5-1
...
 - update Polish translation (Piotr Drąg (raven))
...
which is 3201 bytes.

Exception Handler Information
Traceback (most recent call last):
  File "/usr/share/rhn/satellite_tools/reposync.py", line 141, in import_packages
    self.upload_package(pack, path, md5)
  File "/usr/share/rhn/satellite_tools/reposync.py", line 168, in upload_package
    org_id=self.channel['org_id'])
  File "/usr/share/rhn/server/rhnPackageUpload.py", line 168, in push_package
    importer.run()
  File "/usr/share/rhn/server/importlib/importLib.py", line 628, in run
    self.submit()
  File "/usr/share/rhn/server/importlib/packageImport.py", line 308, in submit
    transactional=self.transactional)
  File "/usr/share/rhn/server/importlib/backend.py", line 745, in processPackages
    transactional=transactional)
  File "/usr/share/rhn/server/importlib/backend.py", line 1585, in __processObjectCollection__
    return self.__doDML(dml)
  File "/usr/share/rhn/server/importlib/backend.py", line 1693, in __doDML
    self.__doInsert(dml.insert, dml.tables)
  File "/usr/share/rhn/server/importlib/backend.py", line 1702, in __doInsert
    raise rhnFault(54, str(e[1]), explain=0)
rhnFault: (54, 'ORA-12899: value too large for column "SWUSER"."RHNPACKAGECHANGELOG"."TEXT" (actual: 3004, maximum: 3000)\n', '\n   
  Package Upload Failed due to uniqueness constraint violation.\n     Make sure the package does not have any duplicate dependencies
 or\n     does not already exists on the server\n     ')


Version-Release number of selected component (if applicable):
spacewalk-0.6

How reproducible:
rhnpush/reposync setroubleshoot into spacewalk (we had NLS_LANG=english.AL32UTF8 at one point, which may have caused that single 'ą' character to become a 4-byte wide character...?)

Steps to Reproduce:
1. set NLS_LANG to english.AL32UTF8
2. rhnpush/reposync/etc setroubleshoot
3. receive error
  
Actual results:
traceback

Expected results:
no traceback

Additional info:
rhbz 488195#c25 and in general that entire bug are probably related.  We are temporarily working around it the same way - bumping the text field to 4000 characters.

# cat /etc/sysconfig/i18n 
LANG="en_US.UTF-8"
SYSFONT="latarcyrheb-sun16"

We recently commented out a few places 
The database was created like:

create database
...
  character set AL32UTF8
...

Commenting out NLS_LANG=english.AL32UTF8 in /etc/sysconfig/httpd "fixed" another oracle/character encoding bug, #524265

Comment 1 Michael Mráka 2010-01-20 18:47:22 UTC
String characters were truncated to fit the database column based on lenght in characters. This doesn't work well for UTF8 strings and have to be changed to use byte semantics.

Comment 2 Michael Mráka 2010-01-20 19:54:58 UTC
Fixed by Joshua Roys' patch; spacewalk.git
commit 1561c9278dca728a67d3c22505d64075553260e9
    528214 - Encode DBstrings as utf-8 bytes before truncating
    
    If they are left as utf-8 strings and not converted to their
    corresponding byte sequence, python treats a multi-byte utf-8
    character as one unit.  This causes confusion for things like
    splices, especially the one right below this patch; that splice
    tries to limit the length of the string to the maximum supported
    by the database schema, but fails to do so as it is operating on
    a utf-8 string rather than a byte string.
    
    Side note:  NLS_LANG must be set to an appropriate utf-8 locale.

Comment 3 Michael Mráka 2010-01-29 21:16:51 UTC
Fixed package: spacewalk-backend-0.8.35-1.

Comment 4 Michael Mráka 2010-02-16 12:59:23 UTC
Spacewalk 0.8 has been released


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