Dear Rick, I have been working on a related issue regarding NCHAR and NVARCHAR2 support in PL/SQL procedures. Please review my attachment at Bug 458531 to verify it is in accordance with your proposed solution. Kind regards, Petros Splinakis --
Petros Splinakis | Software Developer
Phone: +420 220 437 039 | Mobile: +420 730 195 858
Oracle Product Development
ORACLE Czech Republic 
| Oracle is committed to developing practices and products that help protect the environment |
From: Rick Curtis [mailto:curtisr7@xxxxxxxxx]
Sent: Wednesday, January 28, 2015 4:05 AM
To: Dev mailing list for Eclipse Persistence Services
Subject: Re: [eclipselink-dev] Support for national character types Since no one had any comments about this approach I'm going to dive in tomorrow. On Wed, Jan 21, 2015 at 4:50 PM, Rick Curtis <curtisr7@xxxxxxxxx> wrote: Finally getting back to this issue. I talked some more with one of my stake holders and discussed wants / vs needs in regards to national character support. We broke this problem down into two separate issues. The first and most important is table creation. They need a generic way to tell the EclipseLink runtime to create String columns as a type that will support national character types (a la unicode). Since they are writing code that will run against any number of databases, it isn't a viable option to specify this information in a @Column annotation (or xml). Unfortunately support for unicode column types isn't fully standard across the range of supported databases. For example, to be able to store the following Java String "\u215c" each database needs to have a column defined in this way: This is problem #1 and can be mostly implemented by way of a new property that can be set on the DatabasePlatform to change how Strings are mapped and each Platform will need to be updated. This only addresses the problem from a table creation point of view. Problem #2 is more involved and entails adding runtime support for JDBC 4.0 setN, etc methods. For the sake of keeping a targeted discussion, I'm going to table issue #2 till the future when myself/others have more time to add full jdbc4.0 support. Without a proper solution for #2, we still have something workable by relying on each JDBC driver to handle unicode values for us. Nearly all of the databases mentioned have some way to configure the driver to properly handle unicode values. Example: Oracle: jvm property -Doracle.jdbc.defaultNChar=true MySQL: jdbc connection property characterEncoding=utf8 SQLServer: jdbc connection property (default) sendStringParametersAsUnicode=true Woa, sorry for the wall of text here... hopefully I didn't scare everyone away. Long story short, I need to add support to the runtime to generically specify that I want all Strings to be mapped to a unicode supporting type. On Wed, Jan 7, 2015 at 8:59 AM, andrei ilitchev <andrei.ilitchev@xxxxxxxxxx> wrote: Take a look at NCharacter, NString, NClob support for Oracle db in org.eclipse.persistence.oracle On 1/6/2015 5:46 PM, Rick Curtis wrote: I've been given the requirement that some users need the ability to tell EclipseLink to treat all Strings as NVARCHAR type rather than VARCHAR. I did a bit of searching around and haven't found much discussion regarding this issue. I know with some jdbc drivers I can rely on some pre jdbc-4.1 workarounds (sqlserver SendStringParametersAsUnicode), but I'd prefer to stay away from those. I'm wondering if anyone has a feeling for how large of a change this will be? After thinking through this I came up with the following : * Configuration option that is something like 'use national types for Strings'... obviously this is platform dependent. Ideally a future version of the spec will add an attribute to the @Basic type to denote that a given field needs to use national character types. * Updates to the runtime to use proper ResultSet.get/PreparedStatement.set methods for NCHAR, NVARCHAR, LONGNVARCHAR, and NCLOB. -- jdbc 4.1 requirement * Updates to the runtime so that table creation uses the national types. * SQL literals for NCHAR,NVARCHAR,LONGNVARCHAR need a 'N' prefix to the String... that being said I don't think this is an issue because it appears that we (nearly?) always convert JPQL literals to SQL parameters. _______________________________________________ eclipselink-dev mailing list eclipselink-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
--
-- |
