| Summary: | PL/SQL identifier too long | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Mike Norman <michael.norman> | ||||||||
| Component: | Eclipselink | Assignee: | Mike Norman <michael.norman> | ||||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P3 | ||||||||||
| Version: | unspecified | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Mike Norman
Created attachment 209403 [details]
fix very long pl/sql identifiers
Created attachment 209405 [details]
fix very long pl/sql identifiers
When generating the anonymous PL/SQL block, some temp variables
are created based on 'argName'_TARGET (or _COMPAT). If these
variables' names are longer than 30 characters, an exception is
thrown.
The long argName is hashed by a java.security.MessageDigest using
the 'SHA1' algorithm (same as used by Git). The number of bits is
truncated to 112 and then converted to a hex string. The final step
is to prepend 'a_' to the hash value (PL/SQL identifiers can't begin
with a number) creating a brand new 30 character identifier.
The probability of hash collision is extremely low - the IPSEC security
portion of TCP/IP uses 'HMAC SHA1' truncated to 96 bits as per RFC-2104;
the above truncation has 16 more bits.
Created attachment 209406 [details]
fix very long pl/sql identifiers
fixed in SVN 10684:
- when we generate the anonymous PL/SQL block, we often must create temp variables that are based upon the names of arguments to a StoredProcedure. We add the suffix '_TARGET' or '_COMPAT'. Unfortunately, PL/SQL identifiers can only be 30 chars long. - now whenever we find an identifier that is >(30 - LENGTH('_TARGET)), we take the SHA-1 MessageDigest of the identifer. This produces a 160-bit hash value, which is also longer than 30 chars. However, upon doing some research, discovered that truncating SHA-1 hashs to as low as 96 bits is universally regarded as valid (e.g. RFC 2404 IPSEC does this). In version checked in here, we truncate to 112-bits and then prepend '_T' (or '_C') to make a unique, valid PL/SQL identifier
meant to say "prepend 'T_' or 'C_'", not '_T' The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |