[
http://issues.apache.org/jira/browse/DERBY-533?page=comments#action_12319893 ]
Daniel John Debrunner commented on DERBY-533:
---------------------------------------------
I can think of two issues.
1) JDBC constants (java.sql.Types) do not exist for these types until JDBC 4.0.
2) In the existing code, conversions of national character types to and from
datetime and number types applied localization.
I don't know if this approach is correct with respect to the SQL standard, or
in-line with other databases. Ensuring conversions
are correct before allow applications to use them was the reason for disabling
them. Didn't want to get into some backwards
compatibility issues by changing the behaviour to match the standard. I don't
think anyone had time to resolve this.
An example would be converting a DECIMAL of 1.2, to VARCHAR the conversion is
1.2, but in a French database the conversion
to NATIONAL VARCHAR would be 1,2. Is this correct? Similar for conversions from
character types, should 1,2 be converted
to 1.2 in French from a NATIONAL VARCHAR? This is from memory, I know this is
true for the datetime types, but maybe isn't
true for the numeric types (but they are easier to explain and come up with
simple examples :-).
> Re-enable national character datatypes
> --------------------------------------
>
> Key: DERBY-533
> URL: http://issues.apache.org/jira/browse/DERBY-533
> Project: Derby
> Type: New Feature
> Components: SQL
> Versions: 10.1.1.0
> Reporter: Rick Hillegas
>
> SQL 2003 coyly defines national character types as "implementation defined".
> Accordingly, there is considerable variability in how these datatypes behave.
> Oracle and MySQL use these datatypes to store unicode strings. This would not
> distinguish national from non-national character types in Derby since Derby
> stores all strings as unicode sequences.
> The national character datatypes (NCHAR, NVARCHAR, NCLOB and their synonymns)
> used to exist in Cloudscape but were disabled in Derby. The disabling comment
> in the grammar says "need to re-enable according to SQL standard". Does this
> mean that the types were removed because they chafed against SQL 2003? If so,
> what are their defects?
> ------------------------------------------------------------------
> Cloudscape 3.5 provided the following support for national character types:
> - NCHAR and NVARCHAR were legal datatypes.
> - Ordering operations on these datatypes was determined by the collating
> sequence associated with the locale of the database.
> - The locale was a DATABASE-wide property which could not be altered.
> - Ordering on non-national character datatypes was lexicographic, that is,
> character by character.
> ------------------------------------------------------------------
> Oracle 9i provides the following support for national character types:
> - NCHAR, NVARCHAR2, and NCLOB datatypes are used to store unicode strings.
> - Sort order can be overridden per SESSION or even per QUERY, which means
> that these overridden sort orders are not supported by indexes.
> ------------------------------------------------------------------
> DB2 does not appear to support national character types. Nor does its DRDA
> data interchange protocol.
> ------------------------------------------------------------------
> MySQL provides the following support for national character types:
> - National Char and National Varchar datatypes are used to hold unicode
> strings. I cannot find a national CLOB type.
> - The character set and sort order can be changed at SERVER-wide, TABLE-wide,
> or COLUMN-specific levels.
> ------------------------------------------------------------------
> If we removed the disabling logic in Derby, I believe that the following
> would happen:
> - We would get NCHAR, NVARCHAR, and NCLOB datatypes.
> - These would sort according to the locale that was bound to the database
> when it was created.
> - We would have to build DRDA transport support for these types.
> The difference between national and non-national datatypes would be their
> sort order.
> I am keenly interested in understanding what defects (other than DRDA
> support) should be addressed in the disabled implementation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
